-----Original Message----- From: marc lindahl [mailto:marc@bowery.com] Sent: Saturday, October 27, 2001 1:26 AM
What about something where the user can select levels of 'zoom', perhaps out of 10 or 20 possibilities?
Well, the default photo object provides 5 "zooms" as it is. You could define 10 or 20, but as you point out, that would indeed bloat the ZODB or file system. Do you think it's still a reasonable thing to require the developer to preset display sizes, no matter how many and whether or not they're rendered beforehand or on-the-fly?
They're referring to Image, which is of course computation-free. They do suggest that it be used for something with 'expensive' computation, like a database lookup. For many applications, using IM or something for resizing or munging an image would qualify as 'expensive'.
Indeed, it is very expensive. In fact, so expensive in some cases that I hesitate to make it an option even with caching, but I can see how it may be beneficial. The biggest problem I see with using a RAM cache with rendered photos is that many photos of a moderate size could eat a lot of RAM. Take 50 different photos where three rendered sizes average 50k each. Cache them and you've eaten 7.5MB of RAM. My personal site currently has 414 photos with a couple more hundred on the way. If someone went through them all at a single display size, and you RAM cached that one size of each photo at 50k, that's an enormous belly filled with happy memories...nearly 21MB of happy memories. Obviously you would want to put a cap on the RAM cache size, but then you greatly increase the occurrence of the expensive rendering and thus the practical effectiveness of the cache. Am I missing something?
I was thinking that you would have one RAM Cache for the site, not one for each image. So you can control the overall amount of memory. And, it does what a cache is supposed to, which is save the most amount of repetitive re-computation of the same thing (that is, the most popular image sizes).
I was suggesting that instead of using a RAM cache at all, that the displays be created on-the-fly and stored like they are now (in the ZODB or ExtImage). I could then add a timeout property for displays such that when a photo is requested, if the timeout passed for a given display size, that display size would be purged. Would that cause too much write activity for an undoable database? If you set the timeout to a really large number, much larger than a "normal" cache might be, I don't think it would purged less often. I think you'd still end up with only the most popular display sizes taking up space. That is the goal, right? ... having a large number of possible display sizes without them eating ZODB/file system space? Do you see any other problems with this idea? I actually like the sound of it, but I could be overlooking some issues.
For somethings like a photo album, you have only one re-size, which is the thumbnail.
I would consider my site to be a photo album, and I have 5 displays + a thumbnail for each photo. Most people using the Photo product will likely have the same since that's the default.
In any case, cached or stored, will benefit from limiting the user's options. Because, this provides the opportunity for overlap among multiple users, which benefits any type of caching (after all, storing the thumbs is still caching...)
I don't understand what mean. Can you clarify? _______________________ Ron Bickers Logic Etc, Inc.