On Jan 4, 2008, at 4:09 AM, Christiaan Hofman wrote: > Would it make sense to render icons with priorities, so that fast > ones are rendered before slower ones (like web icons)? That would be > more efficient and it looks like it's updated faster.
Well, the web icon renderOffscreen should complete really quickly now, so that much is already happening (and it did make a big difference in that case). The problem I see is that we can't reliably determine which ones are fast or slow, and it can also change depending on the size. Finder icons are fast at smaller sizes, but I see big hits in jp2 decompression at larger sizes (that may change with OS release). PDF icons are slower the first time, but once they're in the disk cache they're really fast at large and small sizes. ImageIO types depend on the file type and size. Given all of that, I think the best way to do it would be to record statistics based on class, size, cache state, etc. in real usage, and look for trends. In lieu of that, I tried reordering icons in the queue so it renders visible icons first, but I think that dropped by the wayside when I added the scrolling stuff. The scrolling heuristics could be tweaked as well, but have to be checked on single and dual proc systems which is a pain. 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 ------------------------------------------------------------------------- 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
