On Jun 15, 2011, at 8:42 AM, Wolfgang Kundrus wrote: > That aside, I am trying to understand, why Cocoa does not flush the > graphics, if there has been drawn something to the window with the a method > that works well otherwise. I understand coalescing updates and I want to > stay away from CGContextFlush as this would cause the application to block, > if another flush has to happen.
I generally agree with Graham that you shouldn't be drawing from a secondary thread. I doubt you're actually achieving anything that couldn't be achieved better on the main thread using the normal display mechanism. All of that said, the Threading Programming Guide <http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html> has this to say about NSGraphicsContext: > If you do any drawing from a secondary thread, you must flush your drawing > calls manually. Cocoa does not automatically update views with content drawn > from secondary threads, so you need to call the flushGraphics method of > NSGraphicsContext when you finish your drawing. If your application draws > content from the main thread only, you do not need to flush your drawing > calls. You would have to obtain the appropriate graphics context by calling +[NSGraphicsContext currentContext] while the focus is locked. Maybe, but not certainly, it would be same context as that returned by -[NSWindow graphicsContext] outside of focus lock on that same thread. I'd be surprised, though, if -[NSGraphicsContext flushGraphics] were not, in the end, a wrapper around CGContextFlush or CGContextSynchronize. You said earlier that: > We have to update a lot of small onscreen objects and performance is way > better, when we travers them outside the Cocoa view tree. However, the "performance" isn't _actually_ better if the drawing isn't flushed to screen except for once a second. And it's also not better if you have to use CGContextFlush and that throttles you to one update per screen refresh. So, I think you're dealing in a fantasy. You're looking at performance that only exists so long as the drawing isn't actually happening. Well, of course that will be faster than the code that actually works. Chances are that, even if you had your ideal mechanism for causing the window context to be flushed once per frame (as opposed to once per lock-unlock of focus on a view), it would probably be no faster than when done via -setNeedsDisplay.../-displayIfNeeded/-drawRect: on the main thread. Regards, Ken _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
