[thelist] javascript slide-show

David Kaufman david at gigawatt.com
Wed Jul 28 12:25:36 CDT 2004


Scott DeMers <demerss1 at msu.edu> wrote:
> I've been given a weird assignment at work. I've been asked to create
> a slide show where 100 images are shown one after the other at rate
> specified by the user (I'll offer something like three choices) on a
> web page - sort of like seting a slide projector on automatic. My
> initial thoughts are to use javascript to create a timer, and then
> refresh the page with a link to the next image at intervals of n
> seconds. Does this make sense? Is their an easier client-side
> solution I'm overlooking?

if they are 100 very small images... (and by "small", i mean it would not be
impractical to load them all onto a single static html page, WRT their
cumulative file sizes and the bandwidth speed of your target visitors) then
i suppose you could use javascript to *preload* all the images, using a
modified JS rollover-like technique and then cycle through the images at
whatever rate you like.

this would have some added benefits.  for instance, once the page, and all
the images were *fully* loaded into the browser (which may be a bit of a
wait), the cycling rate would be much more accurate and controllable as
network latency, at that point, would no longer be a limiting factor (but
then of course browser memory *would*).  also, if you wanted to, you could
even *rewind* using a scroll-bar or dhtml slider control to let the user fly
through this poor-man's  "video" as fast or slow, in either direction, as
their hand can twitch a mouse! :-)

it seems unlikely though that this would be workable "in the real world".
even if the images were only like 2 or 3k each (100 of them yielding a "page
load" size of 300K or more for the browser) this would likely be practical
only for browsers that are accessing an "intranet" webserver on the same
high speed office LAN... it would probably be too slow for garden variety
internet visitors at typical internet speeds unless your webserver was
*very* well-connected, *all* your expected users were also using
well-connected high-speed broadband connections, and all of them had lots of
RAM available for their browsers to chew up :-)

also don't forget that, even under ideal network conditions, you'll want to
consider how many simultaneous users you'd expect to be serving these images
for, whether your server can handle that traffic volume (page-load times
number of simultaneous visitors), and what affect that expected traffic
level might have on your bandwidth costs, if sustained over a period of
hours, days, weeks (think: what if my cool app gets slash-dotted?) if it is
to be publicly internet-accessible.  of course, these last considerations
apply whether you use image-preloading or static links!

hth,

-dave




More information about the thelist mailing list