Dynamic versus Cached Thumbnailing in GDI+
It seems quite a few projects are starting up to perform the common task of creating an image or photo gallery software. Some of these projects are just for managing small collections of photographs located on your local hard disk, others are allowing the addition of a meta-data style database of information, and the latest are allowing disconnected style operation through a shared web space. All of these are great applications since the current trend in home computing is really starting to focus on a kind of connectedness amongst friends and family. Voice, video, and photographs are beginning to pop up on the web and web spaces are being used to chronicle the lives of entire families, rather than the classic photo album of the past.
So I'll share some of my experiences with thumbnailing and image management software that I've worked on and maybe that will help people make decisions on how they approach the creation of their own photo gallery software.
The first item, and the title post, involves the aspect of caching thumbnailed images. You'll notice that the shell does this for you at times using a type of thumbs.db file that sits on your hard-disk, but you can turn this feature off. In general, when you already have one copy of the image on the disk, the true image with full resolution, that is going to be the image you want to use when creating a display for the user. Now, what does happen when you cache the thumbnails? Well, you have to create a storage format first off, so you'll be using the BinaryFormatter most likely. Then you have to store information about the last time the file was touched, in case it changes and you need to update your cached thumbnail. Finally, whenever the user wants the thumbnails in a different size you have to drop your entire cache and re-thumbnail. So basically, what am I trying to say? Well, I'm trying to define a scenario, wherein you are running locally on the user's machine and the images are already at your disposal. In this scenario you should simply thumbnail on demand, cache in memory while the program is running, and not worry about creating a persistent cache that needs to be reloaded the next time the user loads the application.
This scenario starts working when you realize how fast the thumbnailer really is. Most of the time, you run thumbnails on the UI thread, and the UI hangs, and everything sucks for the user. If you are displaying 40 thumbnails, it probably takes 10 seconds before they all complete and the user regains control of the UI. However, if you throw the thumbnailer off on it's own thread, you'll quickly see that you can thumbnail 2+ images per second and that these thumbs can be displayed as they become available in your UI and the user will still have full control over their experience.
I don't want to turn people completely off from thumbnail caching though. There are times when cached thumbnails make sense. Especially when you are writing a client that interacts with a remote data store. When you are running a scenario where download speeds and access to full size pictures becomes an issue, then you'll need to re-examine thumbnailing and caching those thumbnails on the client so they are available without taking a huge hit from the web.
I'm being prompted to head out for dinner now, but once I get back tonight I'll toss up an article detailing thumbnailing speeds, and how to use the thumbnailer asynchronously to provide your user with a real-time experience without resorting to caching.