On 4 Jan 2008, at 6:23 PM, Adam R. Maxwell wrote: > > On Friday, January 04, 2008, at 08:52AM, "Christiaan Hofman" > <[EMAIL PROTECTED]> wrote: >> >> On 4 Jan 2008, at 5:10 PM, Adam R. Maxwell wrote: >> >>> >>> 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 >>
That sounds like being inefficient. Can't we just collect rendered icons until the main thread is ready, rather than flushing every 5 icons? 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? >> The idea I had is to give icons that were already rendered or cached >> high priority, so they don't have to wait for icons that need to be >> drawn. This could be done in the iconQueue, basically by making >> several runs over the loop: first only treat the ones that don't need >> (slow) rendering, then render the rest (perhaps in several loops, for >> faster/slower icons). > > In theory, icons that are already rendered are not in the queue > (unless I screwed up; quite possible). Or do you mean the icons > that have a thumbnail but need to render a full image? I agree > that this and a disk cache check is a potential win, although only > the disk cache is likely relevant for BD since icons are > ephemeral. The thing about reordering in the queue is that the > view specifies order by visibility, so you could end up giving high > priority to icons that are not visible or being scrolled out of > sight; in that case, it would actually appear as a slowdown. So I > think ordering would have to be ranked by visibility, thumbnail, > disk cache, and possibly be done in the view for consistency. > During scrolling, it all goes out the window, so to speak... I was mostly thinking about the cached icons (the part of renderOfScreen with the early return). Some testing however did not appear to give much speedup though. 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
