2010/8/24 Bjørn Ruberg <bjorn@...>:
> On 08/24/2010 12:48 PM, Terry Burton wrote:
>> I have several Munin host screens that consist of hundreds of graph
>> images. Often the information that I require is in sets of images
>> embedded towards the bottom of the page so I have to wait some time
>> for these to render.
>> natural top to bottom image load sequence by "top queueing" the graphs
>> that are within the visible view of the browser to ensure that these
>> are requested first, followed by those graphs that are out of sight.
>> Effectively what you are looking at will load as quickly as possible
>> irrespective of where it is on the page. The new Google Images layout
>> is a good example of this.
>> would load in their normal sequence, i.e. following the principle that
>> essential for it.
>> Does this sound like useful functionality and has this technique been
>> discussed before?
> You might want to consider "lazy load":
> http://www.appelsiini.net/projects/lazyload (or one of its alternatives,
> I seem to remember there's a few).
> This JS snippet doesn't load images outside the viewing area
> ("viewport"), but waits until you start scrolling.
> I briefly look into this earlier for Munin purposes but abandoned the
> (very shallow) testing as it seemed that lazyload would load the images
> from the top down, i.e. moving directly to a graph at the bottom of the
> page would require all images to load anyway.
> However, it's been quite some time since I tested it last, so things
> might have been improved in the library; if not, it may be easy to fix
> in JS.
Thanks for the link which I'm sure it will be helpful in putting
together the relevant JS code.
Rather than use LazyLoad I think that I would prefer to put together
something that doesn't depend on jQuery. I would also prefer that the
JS work with the DOM of the page so that the munin-html templates
src="..." /> rather than any special mantra around the images. This
would help to keep the feature self-contained and make it trivial to
enable and disable.
I guess it would be easier to accept a minimally invasive .js file
with no external dependencies into the Munin codebase?
All the best,