On 5 Jan 2008, at 6:36 PM, Adam R. Maxwell wrote: > > 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.
I don't notice too much difference with this change, so it does not seem to lead to a block. Christiaan ------------------------------------------------------------------------- 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
