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 > >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... ------------------------------------------------------------------------- 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
