discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MacOSX compatibility : detachDrawingThread:toTarget:withObject:


From: Pierre-Yves Rivaille
Subject: Re: MacOSX compatibility : detachDrawingThread:toTarget:withObject:
Date: Mon, 20 Aug 2001 14:36:32 +0200 (MET DST)

On Sun, 19 Aug 2001, Adam Fedor wrote:

> Pierre-Yves Rivaille wrote:
> 
> >> From what I understood, to have a thread to draw something you would need
> > to create using this call, and to put the drawing code between
> > [NSView -lockFocusIfCanDraw] [NSView unlockFocus]
> > rather than
> > [NSView -lockFocus] [NSView unlockFocus]
> 
> lockFocusIfCanDraw seems like a different locking mechanism (like a 
> conditional lock), so  if the detached thread implemented it, than the 
> main thread would have to (and all the AppKit drawing, etc). Clearly 
> that's not how it's done as it would require a major rewrite of the 
> AppKit.

Well, I thought about it this week-end and read carefully Apple's docs.
So lockFocusIfCanDraw is not an interthread lock, it is just meant to
prevent you from drawing to a window where drawing cannot occur because
of its state, e.g. to a minimized window, and not because of concurrency
problems (another thread is also drawing).

I think (I will check as soon as I get back to my MOSX cube) that
multithread drawing is implemented through multiple context.
I guess that to be able to draw in another thread you would do something
like :

  [NSGraphicsContext setCurrentContext: 
             [NSGraphicsContext graphicsContextWithWindow: window]];
  if ([self lockFocusIfCanDraw])
  {
    ... // drawing code
    [self unlockFocus];
  }

So the problem is does GNUstep backend (xgps/xdps) support multiple
contexts ? According to the NEWS file in dgs, it seems that the support is
not so good when using xdps + dgs.

The first problem I found when using xgps with the previous chunk of code,
is in [NSWindow gstate] which gives back a value which is related to the
main thread context and causes a crash when called by a thread using its
own GraphicsContext.
I believe this issue could be solved by using a map table of graphics
contexts and window's gstates, also I've not yet tried. 
I also believe in will not be this only issue :(

Should I try to go further in this direction or am I going into a
dead-end ?

Pierre-Yves Rivaille




reply via email to

[Prev in Thread] Current Thread [Next in Thread]