Re: iPhoto-like scroll view
Re: iPhoto-like scroll view
- Subject: Re: iPhoto-like scroll view
- From: Chris Williams <email@hidden>
- Date: Sat, 08 Sep 2007 08:05:07 -0700
- Thread-topic: iPhoto-like scroll view
I am working on an app right now that manages folders of images, some with
tens of thousands of images. I am creating thumbnails and allowing the user
to work with a folder at at time. So I have an equivalent issue of managing
and displaying thousands of thumbnail images at a time. I have it working
effectively today, performance is super, here's my approach:
I am using a custom view in an NSScrollView. I have an array for the
current folder that holds all the pertinent info (filename, date, size,
database record id, and an NSImage for the thumb). I load it all except the
thumb when I go into a folder. In my drawRect, when I go to paint the image
for a file, if the thumb NSImage is nil, I load the thumbnail image from the
database, and then paint it. If it's there, I just paint it. It works and
displays very quickly.
The problem is that you can't have several thousand NSImages around. You'll
run out of memory. So, I have a "cache" scheme. I keep count of how many I
have loaded, and if I hit my limit (I have a preference for this, but my
starting number is 250), I toss some of them so that I never have more than
so many at a time. My cache scheme is pretty modest, but still figures out
what direction you're scrolling and disposes of the ones at the other end of
the "window" that you're looking at. This works fine and you can scroll
through the folder almost as fast as you can hold the scroll control.
Important note, making a thumb is expensive, you have to make them at most
ONCE, not every time you need them. It will kill your performance. I store
the premade thumbs in the database, don't know what you can do in your
application, but this is a must. I used the logic someone else in this
thread noted to make the thumbs, but reading images off a disk and scaling
them is hard work. It takes about 1-2 seconds per image. If you have even
jut 50 in your scrollview, obviously you can't do it on the fly.
Hope this helps, if you want more info on how I'm handling it, let me know.
Chris
> From: Torsten Curdt <email@hidden>
> Date: Sat, 8 Sep 2007 03:52:02 +0200
> To: Mailing Cocoa List <email@hidden>
> Subject: iPhoto-like scroll view
>
> I am currently experimenting with a custom view that basically shows
> thumbnails like iPhoto does. Now while the basic drawing is still
> terrible inefficient (loads NSImages on every drawRect(), so it still
> needs caching ....and let's not talk about the memory leak (flood?)
> of the current code), what I am really wondering is something else:
>
> Let's assume performance is bad to draw the rects that need an
> update. This somehow results into a very slow feeling of the
> application when I use the window scroll bar. What I am wondering is
> how to keep that still snappy and maybe just skip a few updates.
> Because when I scroll the bar at a very high speed I really only car
> about the final position of the bar. So how would I get the drawing
> to be a bit more lazy. Only do the update when the speed of the bar
> becomes slower. Does that require drawing to happen in different thread?
>
> Something related would be to only draw empty rects when the speed of
> the slider becomes too high. And then switch back to a full display
> at lower speeds. How could this be done?
>
> Any wise words?
>
> cheers
> --
> Torsten
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden