[Top][All Lists]

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

Re: MacOSX compatibility : detachDrawingThread:toTarget:withObject:

From: Adam Fedor
Subject: Re: MacOSX compatibility : detachDrawingThread:toTarget:withObject:
Date: Sun, 19 Aug 2001 20:41:20 -0600
User-agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.2) Gecko/20010630

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]

I would like to implement this behaviour in GNUstep, however I have no
clue on how to start implementing it (not even on whether it can be easily
Could anyone give me clue(s), hint(s), warning(s) or whatever might be
relevant ? I would be very thankful.

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.

I'm thinking that somehow the context can block (or spool?) drawing in the main thread while the detached thread is drawing. That's still hard, but more manageable since it's confined to the graphic context. Blocking doesn't seem like a good idea as that would block the whole application. Spooling would be a better idea. However our drawing implementation doesn't really lend itself to that (every drawing method would have to call a spooling function if the detached thread was drawing).

Perhaps there's other methods. In any case it will take a lot of thought to implement correctly.

Adam Fedor, Digital Optics            | Fudd's law of opposition: Push
address@hidden  http://www.doc.com     | something hard enough, and it
address@hidden  http://www.gnustep.org | will fall over.

reply via email to

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