Great software, great support.
I'm going to plus one this old post and reopen an old and ongoing flame to add to the vote, add my reasoning,add a little comparison to gallery3, and some observations about caching performance in zenphoto.
First it's clear there is little reasonable argument that making a browser ever (even just for the first user) wait to produce an image that could have been produced before is a user feature. Placing the fancy words ''on the fly'' on it doesn't change that fact.
This is primarily a coding feature, not a user feature, and the nice sounding words apply in that context. I suspect it makes it far easier to allow themes to use any size image and not worry about it, and probably other similar brilliance as well as just generally allowing the programmer to automate caching and be done with it (no need to add a do_caching_now call in every new image add method or theme change). I read an old blog post about zenphoto saying that it once was possible to link to arbitrarily sized images to blogs. Ok so the ABILITY to make ''on the fly'' images has a user (blogger) benefit but failing to pre-cache still does not help anyone. It's easy for programmers to confuse coding brilliance with user "features".
I just setup a gallery in gallery3. It went smoothly enough but development direction and support seems fragmented/vague and usability features are maybe a little lacking, at least some including easy image upload features. So, I headed here. Gallery3 probably can't touch how easy it was to copy my whole gallery album structure into ZenPhoto (but then by the time I pre-cached by hand that advantage disappeared, and maybe G3 server add can handle a hierarchy). However, the one thing I like enough about gallery("pre-caching") to DEFINITELY keep me from using zenphoto for now anyway, is being advertised here as a feature and fixing it is being declared as something that isn't really useful.
So why do I think pre-caching is so useful? Because caching takes a ton of memory and/or disk access[* see note below] and web browsing happens in parallel, even with just one user. If you have 100 users browsing pictures and each image takes 5MB of RAM, ok. Now have 100 hundred users each ask to create image caches. To resize the image the full bitmap is stored in memory, often 20 times bigger than the disk file. So now instead of 500MB of ram, that's 10GB of RAM. Well you say reduce the number of apache instances. Why should I? That number of instances is just fine if I serialize the image resizing on my own terms. The argument that ''on the fly'' somehow helps with large servers to handle incremental image additions seems odd. In the end the work required is what it is and delaying it doesn't help the load on the server in any way. Gallery3 keeps track of which files need updating and only incrementally updates those. No problem.
I'm running a small unprofessional server for fun and with other primary purposes. It has fast disk io and more than sufficient bandwidth for its needs to deliver its users full screen images instantly and full size images painlessly. However it is old and is limited in CPU power and even more in RAM(especially being in a VM) and grinds to a near halt or even crashes(ok I need to discipline oom-killer) if I hit the slideshow button with un-cached images. This doesn't happen with gallery3. Maybe I'm completely misdiagnosing this somehow. I would think resource usage would be important to high-powered hosted setups too.
The Solution:
Ok, so you say the community can support this and a plugin exists. Thanks, but I can use themes in G3 and there "precaching" is supported. To do this right some interface should exist that allows themes to declare their pre-caching needs. That is probably so trivial (just a list of resolutions) that a dev could even modify all well known community themes very quickly rather than break compatibility. This should be extremely simple but probably requires core support unless every theme includes their own pre-cacher. I'm sure G3 must have exactly that since different themes do rebuild thumbnails in g3 too in a uniform way. Of course from a programmer perspective ZenPhoto was "not designed to work that way" translated: was designed to allow the programmer to be lazy(no offense, oversimplification acknowledged too) and not need to do that. I love programming simplicity, but it's NOT a user feature.
[*]As for disk access it seems like ZenPhoto is doing a bunch of disk access for these resizes, writing the large bitmap files to /tmp. I don't know enough about imagemagick. It's not clear to me that writing to disk is necessary or ideal. Disk cache might make it not much of an issue though, at least if not too many resizes are happening at once. I'm not sure. Even so, that probably doubles the RAM usage and might be avoidable. I don't claim to begin to know the whole story here, but G3 does seem to me to do the caching faster with less resources. I might try moving my /tmp to a ramdisk and see what happens.
