Thank you both for your replies. Regarding the initial problem of
preloading the images, I figured out what was wrong.
The problem I was having wasn't actually a *preloading* problem (even
though that's how I thought of it at first), but
rather a sequence issue. The images were in fact being 'preloaded,'
but because the time from when they started to be
preloaded and the time when they were being displayed was 0, the
effect was the same as if they were preloaded. My case
is different from simple hover buttons and the such because the images
I wanted to load are dynamic, and only determined
after the user takes some action (at which point they need to be
loaded immediately).
The solution was to create an event listener for each images "load"
event. The event handler simply increments a counter
(numLoaded), and checks to see whether it is equal to the total number
of images. Once that condition is true, the old
image dom-nodes can be removed. This guaranties two things: 1) That
when the new images are loaded, they load at (about)
the same time, which is important for me since they are parts of a
larger single image, and 2) that there is no visible
gap between the old images and new ones (Before, there was a period
after the old images had been removed and before the
new ones were added when the screen was blank).
In regards to the issue of where to store the images I appreciate the
suggestions. In fact, originally, the images *were*
kept in the filesystem, but due to the very large number of images (>
1 million), and limitations from the number of i-nodes
we are allowed to occupy on our web-hosting, we shifted to the
database approach. This also made things slightly simpler
in that both the images and their associated meta information was kept
in a single place, and could be fetched in a single step.
If the performance hit from storing images in the database is very
significant, however, it may be worthwhile to try and
find a way to get back to using the filesystem. Would you happen to
know of any references comparing the two approaches?
Thanks again for the feedback and suggestions.
Take care,
Keith
On Jul 18, 2:02*pm, Bart Van der Donck <b...@nijlen.comwrote:
Thomas 'PointedEars' Lahn wrote:
Keith Hughitt wrote:
I am having trouble preloading images in a javascript application, and
was wondering if anyone had any suggestions. Basically I have a bunch of
images stored in a database as BLOBs.
That might not be the best approach. *BLOBs increase the size of your
database heavily, thereby reducing its performance and that of the server.
You might want to use the filesystem for storing image files instead; it is
optimized for this kind of data. *Then you can store only the path ofthe
file in the database, which is optimized for that kind of data, and letthe
server-side application handle the rest.
That is a good step indeed, but still a waste of database memory. The
uploaded image needs to get a name on server anyhow - just calling it
2546.jpg for record ID 2546 saves one long data column. And the more
images in a record, the more memory is saved (like 2546-A-thumb.jpg
etc.)
--
*Bart
