At 1:18 PM -0700 4/18/06, Dave Wooldridge wrote:
(A) -- Use a REALdatabase file to store the folderitem's GetSaveInfo as one field and the folderitem's 4kb Thumbnail pic in another field (blob). When needing to load a specific thumbnail in the list, the DB is searched for the folderitem and when a match is found, pull the related thumbnail picture from the DB.
This is nice and neat, provided you have a good way to convert a picture to/from a string for storage in the database. Except, perhaps, using GetSaveInfo as a key -- see below.
(B) -- Save the thumbnail as a small 4k image in a cache folder on disk, and then use a REALdatabase file to store the folderitem's GetSaveInfo as one field and the Thumbnail's folderitem GetSaveInfo as another field. When needing to load a specific thumbnail in the list, the DB is searched for the folderitem and when a match is found, use the related thumbnail folderitem data to go fetch the Thumbnail on disk and OpenAsPicture.
This might be a problem, as described, since I don't think there's any guarantee that the GetSaveInfo returned for a certain file tomorrow will be the same as a GetSaveInfo string for it returned today -- it may depend on what other files are mounted, the state of file sharing, the phase of the moon, etc. I realize that this affects both proposals, of course.
I do think you're onto something here, though. You might consider using the AbsolutePath of the image file as the lookup key with either scheme. I know, I'm always saying never to use AbsolutePath, but it may be justified in this case -- if the user does have two volumes mounted with the same name, and an image has exactly the same path on both, it's probably the same image anyway (since one volume is most likely a backup copy of the other). So the thumbnail would match both versions.
Alternatively, you could compute an MD5 of the image file contents, and use that to verify that it matches the cache (i.e., you'd store the MD5 hash along with the thumbnail). This has the nice effect of forcing your thumbnails to update if the images are changed -- which may or may not be an issue in your case.
The advantage of method -A- is that it nicely contains the entire cache in one single DB file instead of a messy folder of thousands of small thumbnail images, but I worry that pulling a 4kb Picture out of a REALdatabase blob field could be slower than simply fetching a small 4kb folderitem.OpenAsPicture.
Right, it probably would be. I'm not sure how much slower, though. Personally, I'd just use individual files, because the database seems like overkill for a simple cache -- most web browsers and email clients cache images as individual files, so why not you too?
I know that Dictionaries are very fast, but if someone has an image collection of literally thousands of images, then loading an entire cache of thousands of thumbnails into a Dictionary into memory could require some seriously hefty RAM allocation. For example: 4kb x 10,000 images = 40 MB of RAM.
Yeah, but on the other hand, it's only 40 MB of RAM. That's not very much, and the VM system on any modern OS will cheerfully page out most of that if it's not accessed in a while. If you really do need this cache to be good only while the app is running, then I'd just do that.
If you want to limit the memory used (or provide an option to do so), here's one approach: keep your cache in the form of an array, where each entry has the FolderItem (or some key generated therefrom) and the corresponding thumbnail. When you need a thumbnail, you scan this array sequentially, until you find the right entry or exhaust the array. When you find it, you pull it out of its position and insert it at the top of the list, so it'll be found first next time. If you don't find it, you create a new entry (and thumbnail), and insert it at the top of the list, and delete the item at the other end of the list if it's reached your limit. This way, recently-accessed stuff stays near the top of the list, and stuff you haven't needed in a while cycles out.
Of course, this is exactly what VM does already, and it can probably do a better job of it -- at the last WWDC I went to, the Apple engineers were actually suggesting that you DON'T pull such tricks, and instead just keep everything in memory and let VM sort it out. But YMMV.
HTH, - Joe -- Joseph J. Strout [EMAIL PROTECTED] _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
