On Jan 5, 2008, at 9:15 AM, Christiaan Hofman wrote: > > On 5 Jan 2008, at 5:51 PM, Adam R. Maxwell wrote: > >> >> 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. >> > > Ready means that the delegate method has returned. The same as what > waitUntilDone:YES would do, only it would not block the render thread > during that time.
Ah, that does make sense. I just changed it to waitUntilDone:NO, so give that a try and see how it performs too. I also fixed a couple of problems with redundant rendering that I woke up thinking about :(. Based on the comment, I'm pretty sure something like that was the problem I ran into last time. ------------------------------------------------------------------------- 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
