On Jan 5, 2008, at 4:22 AM, Christiaan Hofman wrote: > > On 4 Jan 2008, at 6:23 PM, Adam R. Maxwell wrote: > >>>> I found that drawing speed also acts as an implicit throttle on the >>>> render thread, so the queue uses waitUntilDone:YES. I found that >>>> rendering was too fast under some conditions, and all the drawing >>>> updates led to a beachball. Using OpenGL to draw might be a >>>> performance win, but I've been afraid to open that can of worms; >>>> maybe >>>> on a branch. Apple uses mipmaps in iPhoto according to class-dump. >>>> >>>> -- >>>> adam >>> > > That sounds like being inefficient. Can't we just collect rendered > icons until the main thread is ready, rather than flushing every 5 > icons?
What do you mean by "ready?" All the delegate method is really doing is adding some dirty regions for display, so they're redrawn on the next pass through the event loop. > I'm thinking of putting a main thread method in the iconQueue > in between the render thread and the delegate method. It would send > the delegate method and when it's done notifies the render thread > (e.g. using OSAtomic). The render thread can then flush only when the > main thread is ready (perhaps with a minimum number of items to > flush), otherwise it just collects the rendered icons. Perhaps for > the last batch it would waitUntilDone. Does this sound like it could > work? I'm afraid I don't follow; again, this depends on what you mean by the main thread being ready. It's fastest in terms of wall clock time to render all icons and then only redisplay at the end, but that wasn't a good user experience. Come to think of it, I also recall that waitUntilDone:NO improved performance on single-core and killed it on dual-core. That may not be the case now, since the delegate method only marks certain regions for redisplay...and other parts handle that better as well. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bibdesk-develop mailing list Bibdesk-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
