Best image preloading practice?

[darkflame]

I have quite a large app being developed, and requires various large
images to be displayed at certain times.

As the app (rather, a educational game) has a login screen, it makes
sense to start loading the images while the user is login in, and in
the order of the images appearance.

I thought I handled this ok with a while loop, going over a list of
images and using ;
Image.prefetch(URL);
To get the images ready.

However, from what I can tell, this is slowing down some systems (CPU
wise). I think this is because I'm effectively telling all the images
to load at once without a pause.
Whats the best practice for loading a large number of images in a set
order?

You can actualy see the game here;
http://www.cuyperscode.com/CuypersCode2/CCIIstart.html
But its in Dutch.



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best image preloading practice?

[doopa]

Hi,

The key is to use ImageBundles or use one large image that contains
all the icons you want to use and then draw only parts of them when
you want it displayed.

http://code.google.com/p/google-web-toolkit/wiki/ImageBundleDesign

How that helps.

On Feb 3, 5:50 pm, darkflame  wrote:
> I have quite a large app being developed, and requires various large
> images to be displayed at certain times.
>
> As the app (rather, a educational game) has a login screen, it makes
> sense to start loading the images while the user is login in, and in
> the order of the images appearance.
>
> I thought I handled this ok with a while loop, going over a list of
> images and using ;
> Image.prefetch(URL);
> To get the images ready.
>
> However, from what I can tell, this is slowing down some systems (CPU
> wise). I think this is because I'm effectively telling all the images
> to load at once without a pause.
> Whats the best practice for loading a large number of images in a set
> order?
>
> You can actualy see the game 
> here;http://www.cuyperscode.com/CuypersCode2/CCIIstart.html
> But its in Dutch.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best image preloading practice?

[darkflame]

No, this is a large number of very large images, bundles are not
approporate as that would mean they would all be loaded at once, and
the user would have to effectively preload the whole game.
This is not about icons, but actual images. (as it, 640x480 or in some
case's much larger).

On Feb 4, 10:42 am, doopa  wrote:
> Hi,
>
> The key is to use ImageBundles or use one large image that contains
> all the icons you want to use and then draw only parts of them when
> you want it displayed.
>
> http://code.google.com/p/google-web-toolkit/wiki/ImageBundleDesign
>
> How that helps.
>
> On Feb 3, 5:50 pm, darkflame  wrote:
>
>
>
> > I have quite a large app being developed, and requires various large
> > images to be displayed at certain times.
>
> > As the app (rather, a educational game) has a login screen, it makes
> > sense to start loading the images while the user is login in, and in
> > the order of the images appearance.
>
> > I thought I handled this ok with a while loop, going over a list of
> > images and using ;
> > Image.prefetch(URL);
> > To get the images ready.
>
> > However, from what I can tell, this is slowing down some systems (CPU
> > wise). I think this is because I'm effectively telling all the images
> > to load at once without a pause.
> > Whats the best practice for loading a large number of images in a set
> > order?
>
> > You can actualy see the game 
> > here;http://www.cuyperscode.com/CuypersCode2/CCIIstart.html
> > But its in Dutch.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best image preloading practice?

[gregor]

I'm not sure this a "best practice" issue as such - I think you may
have more of an "edge case" here. I've tried your game (although I
can't understand what to do after first screen), but what happens is
that the browser is slogging away downloading data (presumably your
images) which gives gutter messages and hour glasses etc. This is very
distracting, but if you had to wait for the whole lot to download
before the game started you'd probably get bored and go somewhere
else.

I would have thought the best approach might be to download the images
as required for each level as the player advances through the game,
and I would think displaying a "Loading area..." type message after
they have completed a level is a traditional approach for games,
especially giving them something to read whilst they are waiting.

This approach is not so well served by GWT because AFAIK you can only
have one ImageBundle per module and in any case it is downloaded on
initial page load. You may find this thread interesting:

http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/1106bc10356e9880/60fc5167fe4b1040?lnk=gst&q=multiple+module+bruce+ian+buffoon#60fc5167fe4b1040

In it Bruce Johnson comments:

4) History is the answer to apps that are "too big". If you combine
the
points from #2 and #3 above, hopefully it makes sense that whenever
you fear
your app is becoming "too big" for a single page, all you need to do
is
split it into multiple pages such that each page has a unique module
with a
unique entry point. History smooths all the page junction points, and
the
compiler is smart enough to eliminate code you don't use from each
page's
entry point(s).

Which would appear to answer the one ImageBundle per module issue and
provide convenient inter-level load points. However I would also read
what Reinier has to say about it as he also knows what he's talking
about. It would certainly complicate your program.

Failing that, you could consider handling image strips yourself. You
assemble a single composite image manually of all images required for
a single level in some convenient extraction grid. Then you use an
Image object for this composite image, but before you give it the URL,
you attach a LoadListener to it - this is so can tell when its
finished loading in your code and control the loading message and the
UI during level load procedure and kick off extracting the individual
image parts etc.

It's a bit tricky to extract bits of one image to create several
others in your own code. I did it once for an experiment, it looked
like this:

Image sampleImage = new Image(someURL)
.
.
HTML box = new HTML();
Node imageClone = sampleImage.getElement().cloneNode(false);
box.getElement().appendChild(imageClone);
grid.setWidget(i, j, box);
Image part = Image.wrap((Element)imageClone);
part.setVisibleRect(7,7,10,10);

The problem I found is that you can use an  Element to make a new
Image object (which you can then clip), but it must be attached to the
DOM already, hence the messing about. This works, but I make no claim
that it is the most, or even a reasonably, efficient way to do it.
There may be a much better way to do this in GWT, or you may find that
you can do it better in javascript and use a JSNI interface. It might
be worth searching the javascript forums for some ideas, as I'm sure
this has been done before.

regards
gregor





On Feb 4, 1:37 pm, darkflame  wrote:
> No, this is a large number of very large images, bundles are not
> approporate as that would mean they would all be loaded at once, and
> the user would have to effectively preload the whole game.
> This is not about icons, but actual images. (as it, 640x480 or in some
> case's much larger).
>
> On Feb 4, 10:42 am, doopa  wrote:
>
> > Hi,
>
> > The key is to use ImageBundles or use one large image that contains
> > all the icons you want to use and then draw only parts of them when
> > you want it displayed.
>
> >http://code.google.com/p/google-web-toolkit/wiki/ImageBundleDesign
>
> > How that helps.
>
> > On Feb 3, 5:50 pm, darkflame  wrote:
>
> > > I have quite a large app being developed, and requires various large
> > > images to be displayed at certain times.
>
> > > As the app (rather, a educational game) has a login screen, it makes
> > > sense to start loading the images while the user is login in, and in
> > > the order of the images appearance.
>
> > > I thought I handled this ok with a while loop, going over a list of
> > > images and using ;
> > > Image.prefetch(URL);
> > > To get the images ready.
>
> > > However, from what I can tell, this is slowing down some systems (CPU
> > > wise). I think this is because I'm effectively telling all the images
> > > to load at once without a pause.
> > > Whats the best practice for loading a large number of images in a set
> > > order?
>
> > > You can actualy see the game 
> > > here;http://www.cuyperscode.com/CuypersCode2/CCIIstart.html
> > > But its in Dutch.
--

Re: Best image preloading practice?

[darkflame]

Thanks for your help.
I know this isnt an issue many would come accross, allthough I thought
there might be general methods
for sensible progressive loading of large content.

I should have been a bit more specific with the way the app works,
however, as it really does completely
rule-out using image bundles for these images.
This app is effectively like a game-engine, taking script-files, html
and images from directorys on the sever.
I'm not constructing the game myself, but rather the method used to
create it. The upside of this is its very reusable, the downside is
that all images have to be changable on the fly by other people in the
team with no-codeing knowledge.
Cutting and pasteing images together and clipping them on the client
isnt really workable for this.
Heck, I really dont have much to do with the game story/puzzle
side.I dont speak dutch! :P

I guess in some case you could almost picture the game as a gallery
application, with the images in a sequence and the goal is for the
user to look/comment at one picture while the others are loading.

Its not quite the case that the game is so dividable into levels.
While it does have "chapters" which require specific images, theres
other images that load at different times, and to some extent the game
can be non-liner.
Its perfectly possible to make a traditional text-adventure game in
this engine, for instance.
I have created, however, a "master list" of images and the most likely
order they are needed in.

"I would have thought the best approach might be to download the
images
as required for each level as the player advances through the game,
and I would think displaying a "Loading area..." type message after
they have completed a level is a traditional approach for games,
especially giving them something to read whilst they are waiting."

hmz..
Whats wrong with just loading it in the background as they are
playing? By the time they done the first few puzzles, really thats
enough time for the whole game to have downloaded.
Surely todays machines are easily powerfull enough to handel
downloading in the background while other stuff is going on?
My goal is really to have waiting down to nearly zero, aside from a
few seconds at the start.

Is it a ram issue? A cpu one? I think in total we are only talking
about 20MB of images here, 30MB at most.

I'm thinking there should be a way to load continiously in the
background, but not to burden the browser with too many call's at
once.

Cheers,
Darkflame





On Feb 4, 7:51 pm, gregor  wrote:
> I'm not sure this a "best practice" issue as such - I think you may
> have more of an "edge case" here. I've tried your game (although I
> can't understand what to do after first screen), but what happens is
> that the browser is slogging away downloading data (presumably your
> images) which gives gutter messages and hour glasses etc. This is very
> distracting, but if you had to wait for the whole lot to download
> before the game started you'd probably get bored and go somewhere
> else.
>
> I would have thought the best approach might be to download the images
> as required for each level as the player advances through the game,
> and I would think displaying a "Loading area..." type message after
> they have completed a level is a traditional approach for games,
> especially giving them something to read whilst they are waiting.
>
> This approach is not so well served by GWT because AFAIK you can only
> have one ImageBundle per module and in any case it is downloaded on
> initial page load. You may find this thread interesting:
>
> http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...
>
> In it Bruce Johnson comments:
>
> 4) History is the answer to apps that are "too big". If you combine
> the
> points from #2 and #3 above, hopefully it makes sense that whenever
> you fear
> your app is becoming "too big" for a single page, all you need to do
> is
> split it into multiple pages such that each page has a unique module
> with a
> unique entry point. History smooths all the page junction points, and
> the
> compiler is smart enough to eliminate code you don't use from each
> page's
> entry point(s).
>
> Which would appear to answer the one ImageBundle per module issue and
> provide convenient inter-level load points. However I would also read
> what Reinier has to say about it as he also knows what he's talking
> about. It would certainly complicate your program.
>
> Failing that, you could consider handling image strips yourself. You
> assemble a single composite image manually of all images required for
> a single level in some convenient extraction grid. Then you use an
> Image object for this composite image, but before you give it the URL,
> you attach a LoadListener to it - this is so can tell when its
> finished loading in your code and control the loading message and the
> UI during level load procedure and kick off extracting the individual
> image parts etc.
>
> It's a bit tricky to 

Re: Best image preloading practice?

[gregor]

I'm not sure I can be of much more help on this myself, since I have
never written anything like this, and I have not come across any
specific posts about it I can recall - maybe some members have, so you
can hope

A few ideas/comments in-line:

On Feb 5, 11:42 am, darkflame  wrote:
> Thanks for your help.
> I know this isnt an issue many would come accross, allthough I thought
> there might be general methods
> for sensible progressive loading of large content.

This question does come up quite a lot and has been answered including
in the link I gave you (where it comes from the horses mouth). The
fundamental issue is that the GWT compiler performs serious
optimization at compile time to reduce javascript file size. To do
that it produces a single js file at compile time and does not support
the idea of loading the application in "chunks" unless you do the
multiple module with separate entry point thing. You can read the
thread and others for technical details.

>
> I should have been a bit more specific with the way the app works,
> however, as it really does completely
> rule-out using image bundles for these images.
> This app is effectively like a game-engine, taking script-files, html
> and images from directorys on the sever.
> I'm not constructing the game myself, but rather the method used to
> create it. The upside of this is its very reusable, the downside is
> that all images have to be changable on the fly by other people in the
> team with no-codeing knowledge.
> Cutting and pasteing images together and clipping them on the client
> isnt really workable for this.
> Heck, I really dont have much to do with the game story/puzzle
> side.I dont speak dutch! :P
>
> I guess in some case you could almost picture the game as a gallery
> application, with the images in a sequence and the goal is for the
> user to look/comment at one picture while the others are loading.
>
> Its not quite the case that the game is so dividable into levels.
> While it does have "chapters" which require specific images, theres
> other images that load at different times, and to some extent the game
> can be non-liner.
> Its perfectly possible to make a traditional text-adventure game in
> this engine, for instance.
> I have created, however, a "master list" of images and the most likely
> order they are needed in.

Another classic approach is the "maze" design (I think this is how
trad text adventures where generally done). You have rooms with doors
(or walls) connecting to other rooms. You have the maze defined in a
data structure on the server, and when player gets to a room (i.e. a
location), you download each of the rooms they can move to next which
are specified as properties of the doors. Each room has its associated
script file and images etc. I think this is fairly common and you will
probably find ready made code examples around the web. The Gang of
Four use it as example in introduction to creational patterns chapter
in the famous book.

The big issue is how many separate images are required for each
location. If its basically only one, its easy. You fetch the location
scripts and data for each adjoining room over GWT RPC (very quick)
which includes image ID's. Then you fetch the room image for the room
they go to (again very quick if images are 100-200Kb etc). If several
images, you have a multiple HTTP call problem which you really want to
avoid. That's the idea behind the composite image strip. Much faster.
It's what good image galleries do with thumbs for example.


>
> "I would have thought the best approach might be to download the
> images
> as required for each level as the player advances through the game,
> and I would think displaying a "Loading area..." type message after
> they have completed a level is a traditional approach for games,
> especially giving them something to read whilst they are waiting."
>
> hmz..
> Whats wrong with just loading it in the background as they are
> playing? By the time they done the first few puzzles, really thats
> enough time for the whole game to have downloaded.
> Surely todays machines are easily powerfull enough to handel
> downloading in the background while other stuff is going on?
> My goal is really to have waiting down to nearly zero, aside from a
> few seconds at the start.
>

As I mentioned having the browser download the images via simple URL
to image location is distracting for the player as the browser reports
progress all the time. If you use your own file download servlet
called repeatedly you avoid that problem, it does happen invisibly in
background. Use standard HttpServlet and feed its URL + image ID param
into Image object constructors. Lots of examples for this in group and
around net.

> Is it a ram issue? A cpu one? I think in total we are only talking
> about 20MB of images here, 30MB at most.

You are thinking of loading 20MB of images into the DHTML DOM of you
application. The DOM is maintained by the browser, and it is not
desig

Re: Best image preloading practice?

[darkflame]

"I'm not sure I can be of much more help on this myself, since I have
never written anything like this, and I have not come across any
specific posts about it I can recall - maybe some members have, so
you
can hope..."

Thats ok, anythings welcome :)

"The
fundamental issue is that the GWT compiler performs serious
optimization at compile time to reduce javascript file size. To do
that it produces a single js file at compile time and does not
support
the idea of loading the application in "chunks" unless you do the
multiple module with separate entry point thing. You can read the
thread and others for technical details. "

No,no thats ok, I'm not interested in loading the app in chunks, just
the images.
Everything else can stay.

"Another classic approach is the "maze" ...
The big issue is how many separate images are required for each
location."

The maze design is good, and I could certainly extract the possible-
routes from my script controll.
Allthough its impossible to say how many images there could be really.
If there was 3 or 4 possible routes from a point, each leading to a
location (which might have a picture or might not), and a few items in
each location (each item might have a picture, or even a few), it
quickly adds up.
The maze seems to be a good optimisation, nethertheless, but there
would still need to be a loading-system within it.

". If you use your own file download servlet
called repeatedly you avoid that problem, it does happen invisibly in
background. Use standard HttpServlet and feed its URL + image ID
param
into Image object constructors. Lots of examples for this in group
and
around net. "

Ah, this sounds quite usefull to hide the loading, allthough I'll have
to read up.
I assume this is how, say, GoogleMaps does it?

"You are thinking of loading 20MB of images into the DHTML DOM of you
application"

Am I? Does the DOM keep them there even when not displayed?
These images certainly wouldnt be displayed all at once. 1 or 2 at a
time at most.

I figured I was just giving them a chance to be put in the browsers
cache :-/
Sure, some users might have a heavily restricted cache, or even off,
but I think they are in the gross minority. (and if they have no image
cache, then they probably are used to waiting for images loading
anyway).
But the vaste majority of players should happily be able to load
20-30MB onto their hard disk for the course of the game.

"They
are deliberately designed to make downloading huge chunks of binary
data difficult, especially transparently, and they are not expecting
to have to display 20MB worth of images at once. "

Again, not at once.
Surely a staggered download they wouldnt have a problem with?
Emulating, say, what it would expect from a user browseing DeviantArt?

"If you leave it to the browser, it makes one Http call per image and
you cannot guarantee the order they will be fetched. I"

Yes, I noticed this already. Its interesting, as I expected it to be
in a first-come-first-served base's, but I guess theres some
optimisation within a timeframe.
I do wonder though what the limit of this is and if its the same per
browser. (I mean, if I loaded no more then 1 image every 10 seconds,
it would probably do it in the order I asked, but not if I asked for
one to be prefetched every 10ms)
This is more a curiousity though.

". The point of
the composite image strip is to fetch several images in one request
since they come in a single binary file. "

Yes, I understand the point of them, and I think image bundles are a
great idea.
(In fact, online in general, theres probably a lot of wasted bandwidth
used on little UI elements on webpages..like 5kb gifs etc)
In this specific case though they arnt approperate.
Not unless I got the server to dynamically splice the images together
and the client to cut them up.
But thats beyond the scope of the projects timeframe.














On Feb 5, 3:27 pm, gregor  wrote:
> I'm not sure I can be of much more help on this myself, since I have
> never written anything like this, and I have not come across any
> specific posts about it I can recall - maybe some members have, so you
> can hope
>
> A few ideas/comments in-line:
>
> On Feb 5, 11:42 am, darkflame  wrote:
>
> > Thanks for your help.
> > I know this isnt an issue many would come accross, allthough I thought
> > there might be general methods
> > for sensible progressive loading of large content.
>
> This question does come up quite a lot and has been answered including
> in the link I gave you (where it comes from the horses mouth). The
> fundamental issue is that the GWT compiler performs serious
> optimization at compile time to reduce javascript file size. To do
> that it produces a single js file at compile time and does not support
> the idea of loading the application in "chunks" unless you do the
> multiple module with separate entry point thing. You can read the
> thread and others for technical details.
>
>
>
>
>
> > I should have been a bit more s

Re: Best image preloading practice?

[gregor]

>
> Ah, this sounds quite usefull to hide the loading, allthough I'll have
> to read up.
> I assume this is how, say, GoogleMaps does it?

I think it's quite common where you want to have control over how
images are handled yourself - as I say there are plenty of examples
around of how to do the serlvet.
>
> "You are thinking of loading 20MB of images into the DHTML DOM of you
> application"
>
> Am I? Does the DOM keep them there even when not displayed?
> These images certainly wouldnt be displayed all at once. 1 or 2 at a
> time at most.

I'm not absolutely sure, but I think if you load an image it is
basically attached to a document, whether the browser caches it or
not, and whether it is currently visible of not. You don't control the
browser cache, I mean I don't think you can tell it to conveniently
download all your images and store them neatly on disk until you need
to display them for example. It's also more than likely each browser
does things differently.
>

> But the vaste majority of players should happily be able to load
> 20-30MB onto their hard disk for the course of the game.

That's my point: I don't think it works like that, I can see why it
would be nice for you if it did. The browser probably does store
images locally in some circumstances, but I believe this would be for
virtual backing for the document it's loaded/displaying if required
for memory management purposes. I.e. you've got a document of 20MB
loaded which it must manipulate. I may be wrong, you'd need to
investigate to be sure.

>
> "They
> are deliberately designed to make downloading huge chunks of binary
> data difficult, especially transparently, and they are not expecting
> to have to display 20MB worth of images at once. "
>
> Again, not at once.
> Surely a staggered download they wouldnt have a problem with?
> Emulating, say, what it would expect from a user browseing DeviantArt?
>

yeah, the staggered download is basically the idea of the maze - each
time you move to next location you've only got one locations worth of
images to fetch. Or if it worked fast enough you could fetch all the
required images for the adjoining locations so they would be ready to
go instantly. It depends entirely on no of image bytes per location.

Point is doing it this way old images are thrown away and can be
garbage collected as you go, so you are not accumulating images in
memory. It's stable. (assuming I'm right about the how this works of
course).

> "If you leave it to the browser, it makes one Http call per image and
> you cannot guarantee the order they will be fetched. I"
>
> Yes, I noticed this already. Its interesting, as I expected it to be
> in a first-come-first-served base's, but I guess theres some
> optimisation within a timeframe.
> I do wonder though what the limit of this is and if its the same per
> browser. (I mean, if I loaded no more then 1 image every 10 seconds,
> it would probably do it in the order I asked, but not if I asked for
> one to be prefetched every 10ms)
> This is more a curiousity though.
>
> ". The point of
> the composite image strip is to fetch several images in one request
> since they come in a single binary file. "
>
> Yes, I understand the point of them, and I think image bundles are a
> great idea.
> (In fact, online in general, theres probably a lot of wasted bandwidth
> used on little UI elements on webpages..like 5kb gifs etc)
> In this specific case though they arnt approperate.
> Not unless I got the server to dynamically splice the images together
> and the client to cut them up.
> But thats beyond the scope of the projects timeframe.

This is exactly what the GWT ImageBundle does (and what has been best
practice in web design for years). Annoyingly for you GWT only does
this once per module because Bruce says they can't think of a single
use case for needing separate ImageBundles!  My bet is that if you
just start loading all the images as you are suggesting, you will have
to attach them to the DOM somewhere, so ultimately what you will be
doing is building the entire game at the same time as the player is
trying to play the first locations. So my betting is three to one on
a) whilst this build is going on the game play will be badly affected
at precisely the time you least want it to, and b) once you've loaded
it all it will run like a dog anyway.

I may well be wrong, but if I'm not, and you looked at the maze idea
as plan B, then using image strips a la ImageBundle will make the game
run much faster and smoother, so the effort might well be critical in
the end. This is after all the heart of your technical challenge. This
has been done so many times I expect you will find some javascript
code that cuts them up (or maybe CSS stuff) to crib from somewhere and
some server side tools to pack the image strips as well.




>
> On Feb 5, 3:27 pm, gregor  wrote:
>
> > I'm not sure I can be of much more help on this myself, since I have
> > never written anything like this, and I have 

Re: Best image preloading practice?

[Martin Gorostegui]

Hi darkflame,

I think the best way of (pre)loading images depends on the kind of app you
have. I visited the url you shared with us and run a
Fiddler2session through it to discover that
around 100 requests are fired to get
icons, textures, buttons, gradient bars, etc which could be loaded all in
one request using an ImageBundle and doing that will surely improve the
loading time of the app. Then you have like another 100 requests that fetch
a combination of thumbnails and bigger images with good quality (ranging
from 10kb to 1 meg aprox). For what I saw many of these images are displayed
only when the user clicks on the inventory bag (thumbnails) and then when a
thumbnail is selected the bigger image is displayed so I think you could
also use Image.prefetch to, for example, get all the thumbnails when the
initial screen is loadad (so that when a user clicks on the bag they appear
quickly) and also prefetch the bigger images when the user clicks on the bag
so that when a thumbnail is clicked the big image appears quickly also... or
maybe you could just load a big image when it is needed! I think these are
the kind of decission you can only make by having the app running and using
tools like Fiddler2 or Firebug to see loading times, number of requests, use
of browser cache, etc.

I hope this helps,

Martin

On Thu, Feb 5, 2009 at 5:24 PM, gregor  wrote:

>
>
> >
> > Ah, this sounds quite usefull to hide the loading, allthough I'll have
> > to read up.
> > I assume this is how, say, GoogleMaps does it?
>
> I think it's quite common where you want to have control over how
> images are handled yourself - as I say there are plenty of examples
> around of how to do the serlvet.
> >
> > "You are thinking of loading 20MB of images into the DHTML DOM of you
> > application"
> >
> > Am I? Does the DOM keep them there even when not displayed?
> > These images certainly wouldnt be displayed all at once. 1 or 2 at a
> > time at most.
>
> I'm not absolutely sure, but I think if you load an image it is
> basically attached to a document, whether the browser caches it or
> not, and whether it is currently visible of not. You don't control the
> browser cache, I mean I don't think you can tell it to conveniently
> download all your images and store them neatly on disk until you need
> to display them for example. It's also more than likely each browser
> does things differently.
> >
>
> > But the vaste majority of players should happily be able to load
> > 20-30MB onto their hard disk for the course of the game.
>
> That's my point: I don't think it works like that, I can see why it
> would be nice for you if it did. The browser probably does store
> images locally in some circumstances, but I believe this would be for
> virtual backing for the document it's loaded/displaying if required
> for memory management purposes. I.e. you've got a document of 20MB
> loaded which it must manipulate. I may be wrong, you'd need to
> investigate to be sure.
>
> >
> > "They
> > are deliberately designed to make downloading huge chunks of binary
> > data difficult, especially transparently, and they are not expecting
> > to have to display 20MB worth of images at once. "
> >
> > Again, not at once.
> > Surely a staggered download they wouldnt have a problem with?
> > Emulating, say, what it would expect from a user browseing DeviantArt?
> >
>
> yeah, the staggered download is basically the idea of the maze - each
> time you move to next location you've only got one locations worth of
> images to fetch. Or if it worked fast enough you could fetch all the
> required images for the adjoining locations so they would be ready to
> go instantly. It depends entirely on no of image bytes per location.
>
> Point is doing it this way old images are thrown away and can be
> garbage collected as you go, so you are not accumulating images in
> memory. It's stable. (assuming I'm right about the how this works of
> course).
>
> > "If you leave it to the browser, it makes one Http call per image and
> > you cannot guarantee the order they will be fetched. I"
> >
> > Yes, I noticed this already. Its interesting, as I expected it to be
> > in a first-come-first-served base's, but I guess theres some
> > optimisation within a timeframe.
> > I do wonder though what the limit of this is and if its the same per
> > browser. (I mean, if I loaded no more then 1 image every 10 seconds,
> > it would probably do it in the order I asked, but not if I asked for
> > one to be prefetched every 10ms)
> > This is more a curiousity though.
> >
> > ". The point of
> > the composite image strip is to fetch several images in one request
> > since they come in a single binary file. "
> >
> > Yes, I understand the point of them, and I think image bundles are a
> > great idea.
> > (In fact, online in general, theres probably a lot of wasted bandwidth
> > used on little UI elements on webpages..like 5kb gifs etc)
> > In this specific case though th

Re: Best image preloading practice?

[darkflame]

>
> > "You are thinking of loading 20MB of images into the DHTML DOM of you
> > application"
>
> > Am I? Does the DOM keep them there even when not displayed?
> > These images certainly wouldnt be displayed all at once. 1 or 2 at a
> > time at most.
>
> I'm not absolutely sure, but I think if you load an image it is
> basically attached to a document, whether the browser caches it or
> not, and whether it is currently visible of not. You don't control the
> browser cache, I mean I don't think you can tell it to conveniently
> download all your images and store them neatly on disk until you need
> to display them for example.

ah, pig.
I thought that was exactly that prefetch was doing -sigh-
I thought it loaded it to ram first, then the browser keeps a copy in
its cache for reloading if needed.
-sigh-
That does change things indeed then.


> > Again, not at once.
> > Surely a staggered download they wouldnt have a problem with?
> > Emulating, say, what it would expect from a user browseing DeviantArt?
>
> yeah, the staggered download is basically the idea of the maze - each
> time you move to next location you've only got one locations worth of
> images to fetch. Or if it worked fast enough you could fetch all the
> required images for the adjoining locations so they would be ready to
> go instantly. It depends entirely on no of image bytes per location.
>

Yes, I looks like I'll be switching to a as-you-go-along-it-loads-the-
next-rooms approach.
Allthough...

> Point is doing it this way old images are thrown away and can be
> garbage collected as you go, so you are not accumulating images in
> memory. It's stable. (assuming I'm right about the how this works of
> course).
>

...I'm not sure there will be much that can be chucked away in this
game.
My engine is able to remove items easily enough, but for this game
items from the start of the game are still usefull at the end, so
theres only a few case's when images can be removed never to be
recalled.


> > ". The point of
> > the composite image strip is to fetch several images in one request
> > since they come in a single binary file. "
>
> > Yes, I understand the point of them, and I think image bundles are a
> > great idea.
> > (In fact, online in general, theres probably a lot of wasted bandwidth
> > used on little UI elements on webpages..like 5kb gifs etc)
> > In this specific case though they arnt approperate.
> > Not unless I got the server to dynamically splice the images together
> > and the client to cut them up.
> > But thats beyond the scope of the projects timeframe.
>
> This is exactly what the GWT ImageBundle does (and what has been best
> practice in web design for years). Annoyingly for you GWT only does
> this once per module because Bruce says they can't think of a single
> use case for needing separate ImageBundles!  My bet is that if you
> just start loading all the images as you are suggesting, you will have
> to attach them to the DOM somewhere, so ultimately what you will be
> doing is building the entire game at the same time as the player is
> trying to play the first locations. So my betting is three to one on
> a) whilst this build is going on the game play will be badly affected
> at precisely the time you least want it to, and b) once you've loaded
> it all it will run like a dog anyway.

Yes, I think your right there.
But I think cutting up 30MB of images client side might actualy raise
the required specs of the game :P

>
> I may well be wrong, but if I'm not, and you looked at the maze idea
> as plan B, then using image strips a la ImageBundle will make the game
> run much faster and smoother, so the effort might well be critical in
> the end. This is after all the heart of your technical challenge. This
> has been done so many times I expect you will find some javascript
> code that cuts them up (or maybe CSS stuff) to crib from somewhere and
> some server side tools to pack the image strips as well.
>

I may have miss-understoof how image bundles worked completely here
though, as I originaly thought they were fixed at compile-time.
>From the perspective of people editing the game content (images/text),
what would they have to do?
Run a script file of some sort every time they changed an image in the
game?
Or would the image be spliced together server-side for each user as
they request the javascript? (which would surely increase sever load
and load time too)

I'm thinking strongly of going for the maze-techique now, but still
need the best method/approach for loading within it.
(Basicaly ; "I know theres these 10 large images to be loaded for the
next area, whats the best way to do it so the client dosnt notice the
loading")

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-to

Re: Best image preloading practice?

[Litty Preeth]

>
> > "You are thinking of loading 20MB of images into the DHTML DOM of you
> > application"
>
> > Am I? Does the DOM keep them there even when not displayed?
> > These images certainly wouldnt be displayed all at once. 1 or 2 at a
> > time at most.
>
> I'm not absolutely sure, but I think if you load an image it is
> basically attached to a document, whether the browser caches it or
> not, and whether it is currently visible of not. You don't control the
> browser cache, I mean I don't think you can tell it to conveniently
> download all your images and store them neatly on disk until you need
> to display them for example.

ah, pig.
I thought that was exactly that prefetch was doing -sigh-
I thought it loaded it to ram first, then the browser keeps a copy in
its cache for reloading if needed.
-sigh-
That does change things indeed then.

AFAIK the prefetch creates an IMG element but its not attached to the DOM.

- Litty


On Fri, Feb 6, 2009 at 1:03 PM, darkflame  wrote:

>
>
> >
> > > "You are thinking of loading 20MB of images into the DHTML DOM of you
> > > application"
> >
> > > Am I? Does the DOM keep them there even when not displayed?
> > > These images certainly wouldnt be displayed all at once. 1 or 2 at a
> > > time at most.
> >
> > I'm not absolutely sure, but I think if you load an image it is
> > basically attached to a document, whether the browser caches it or
> > not, and whether it is currently visible of not. You don't control the
> > browser cache, I mean I don't think you can tell it to conveniently
> > download all your images and store them neatly on disk until you need
> > to display them for example.
>
> ah, pig.
> I thought that was exactly that prefetch was doing -sigh-
> I thought it loaded it to ram first, then the browser keeps a copy in
> its cache for reloading if needed.
> -sigh-
> That does change things indeed then.
>
>
> > > Again, not at once.
> > > Surely a staggered download they wouldnt have a problem with?
> > > Emulating, say, what it would expect from a user browseing DeviantArt?
> >
> > yeah, the staggered download is basically the idea of the maze - each
> > time you move to next location you've only got one locations worth of
> > images to fetch. Or if it worked fast enough you could fetch all the
> > required images for the adjoining locations so they would be ready to
> > go instantly. It depends entirely on no of image bytes per location.
> >
>
> Yes, I looks like I'll be switching to a as-you-go-along-it-loads-the-
> next-rooms approach.
> Allthough...
>
> > Point is doing it this way old images are thrown away and can be
> > garbage collected as you go, so you are not accumulating images in
> > memory. It's stable. (assuming I'm right about the how this works of
> > course).
> >
>
> ...I'm not sure there will be much that can be chucked away in this
> game.
> My engine is able to remove items easily enough, but for this game
> items from the start of the game are still usefull at the end, so
> theres only a few case's when images can be removed never to be
> recalled.
>
>
> > > ". The point of
> > > the composite image strip is to fetch several images in one request
> > > since they come in a single binary file. "
> >
> > > Yes, I understand the point of them, and I think image bundles are a
> > > great idea.
> > > (In fact, online in general, theres probably a lot of wasted bandwidth
> > > used on little UI elements on webpages..like 5kb gifs etc)
> > > In this specific case though they arnt approperate.
> > > Not unless I got the server to dynamically splice the images together
> > > and the client to cut them up.
> > > But thats beyond the scope of the projects timeframe.
> >
> > This is exactly what the GWT ImageBundle does (and what has been best
> > practice in web design for years). Annoyingly for you GWT only does
> > this once per module because Bruce says they can't think of a single
> > use case for needing separate ImageBundles!  My bet is that if you
> > just start loading all the images as you are suggesting, you will have
> > to attach them to the DOM somewhere, so ultimately what you will be
> > doing is building the entire game at the same time as the player is
> > trying to play the first locations. So my betting is three to one on
> > a) whilst this build is going on the game play will be badly affected
> > at precisely the time you least want it to, and b) once you've loaded
> > it all it will run like a dog anyway.
>
> Yes, I think your right there.
> But I think cutting up 30MB of images client side might actualy raise
> the required specs of the game :P
>
> >
> > I may well be wrong, but if I'm not, and you looked at the maze idea
> > as plan B, then using image strips a la ImageBundle will make the game
> > run much faster and smoother, so the effort might well be critical in
> > the end. This is after all the heart of your technical challenge. This
> > has been done so many times I expect you will find some javascript
> > code 

Re: Best image preloading practice?

[darkflame]

I use Firebug as well as the inbuilt tools of Chrome quite a lot.
I will check out Fiddler2 though, thanks for the recomendation :)

The thumbnails could be prefetched without problem, and even image
bundled most probably.
However, the bigger images they link too I wouldnt want to load on the
fly because some of these could be VERY big, and
the loading too noticeable to be used as a "game".
Specificaly if you drag the magnifying glass over items it loads a
bigger image version of them in a clipped box, if the bigger image
isnt already loaded, this dosnt
work very well. (actualy, it just looks like the magnifying glass isnt
working at all).

However, I'll check out fiddler and try to use it with the maze-
techique for preloading stuff to optimise.

On Feb 5, 10:28 pm, Martin Gorostegui 
wrote:
> Hi darkflame,
>
> I think the best way of (pre)loading images depends on the kind of app you
> have. I visited the url you shared with us and run a
> Fiddler2session through it to discover that
> around 100 requests are fired to get
> icons, textures, buttons, gradient bars, etc which could be loaded all in
> one request using an ImageBundle and doing that will surely improve the
> loading time of the app. Then you have like another 100 requests that fetch
> a combination of thumbnails and bigger images with good quality (ranging
> from 10kb to 1 meg aprox). For what I saw many of these images are displayed
> only when the user clicks on the inventory bag (thumbnails) and then when a
> thumbnail is selected the bigger image is displayed so I think you could
> also use Image.prefetch to, for example, get all the thumbnails when the
> initial screen is loadad (so that when a user clicks on the bag they appear
> quickly) and also prefetch the bigger images when the user clicks on the bag
> so that when a thumbnail is clicked the big image appears quickly also... or
> maybe you could just load a big image when it is needed! I think these are
> the kind of decission you can only make by having the app running and using
> tools like Fiddler2 or Firebug to see loading times, number of requests, use
> of browser cache, etc.
>
> I hope this helps,
>
> Martin
>
> On Thu, Feb 5, 2009 at 5:24 PM, gregor  wrote:
>
> > > Ah, this sounds quite usefull to hide the loading, allthough I'll have
> > > to read up.
> > > I assume this is how, say, GoogleMaps does it?
>
> > I think it's quite common where you want to have control over how
> > images are handled yourself - as I say there are plenty of examples
> > around of how to do the serlvet.
>
> > > "You are thinking of loading 20MB of images into the DHTML DOM of you
> > > application"
>
> > > Am I? Does the DOM keep them there even when not displayed?
> > > These images certainly wouldnt be displayed all at once. 1 or 2 at a
> > > time at most.
>
> > I'm not absolutely sure, but I think if you load an image it is
> > basically attached to a document, whether the browser caches it or
> > not, and whether it is currently visible of not. You don't control the
> > browser cache, I mean I don't think you can tell it to conveniently
> > download all your images and store them neatly on disk until you need
> > to display them for example. It's also more than likely each browser
> > does things differently.
>
> > > But the vaste majority of players should happily be able to load
> > > 20-30MB onto their hard disk for the course of the game.
>
> > That's my point: I don't think it works like that, I can see why it
> > would be nice for you if it did. The browser probably does store
> > images locally in some circumstances, but I believe this would be for
> > virtual backing for the document it's loaded/displaying if required
> > for memory management purposes. I.e. you've got a document of 20MB
> > loaded which it must manipulate. I may be wrong, you'd need to
> > investigate to be sure.
>
> > > "They
> > > are deliberately designed to make downloading huge chunks of binary
> > > data difficult, especially transparently, and they are not expecting
> > > to have to display 20MB worth of images at once. "
>
> > > Again, not at once.
> > > Surely a staggered download they wouldnt have a problem with?
> > > Emulating, say, what it would expect from a user browseing DeviantArt?
>
> > yeah, the staggered download is basically the idea of the maze - each
> > time you move to next location you've only got one locations worth of
> > images to fetch. Or if it worked fast enough you could fetch all the
> > required images for the adjoining locations so they would be ready to
> > go instantly. It depends entirely on no of image bytes per location.
>
> > Point is doing it this way old images are thrown away and can be
> > garbage collected as you go, so you are not accumulating images in
> > memory. It's stable. (assuming I'm right about the how this works of
> > course).
>
> > > "If you leave it to the browser, it makes one Http call per image and
> > > you cannot guarantee t

Re: Best image preloading practice?

[darkflame]

Heres a few follow up questions, incidently;

a) Is it possible, in all browsers, to tell when a few items have been
prefetched?
I know you can do this if its attached to the dom and your loading an
image normaly. (save for some problems in IE where you have to set a
timer and look for image width...).

b) If I do have to load, say, upto 10 images that have to be seperate,
is it better to just loop over a list of them prefetching and leave it
upto the browseror should I put a timer and trigger a load every,
say, 5 seconds ?
(or dosnt it make much difference).




On Feb 6, 9:14 am, Litty Preeth  wrote:
> > > "You are thinking of loading 20MB of images into the DHTML DOM of you
> > > application"
>
> > > Am I? Does the DOM keep them there even when not displayed?
> > > These images certainly wouldnt be displayed all at once. 1 or 2 at a
> > > time at most.
>
> > I'm not absolutely sure, but I think if you load an image it is
> > basically attached to a document, whether the browser caches it or
> > not, and whether it is currently visible of not. You don't control the
> > browser cache, I mean I don't think you can tell it to conveniently
> > download all your images and store them neatly on disk until you need
> > to display them for example.
>
> ah, pig.
> I thought that was exactly that prefetch was doing -sigh-
> I thought it loaded it to ram first, then the browser keeps a copy in
> its cache for reloading if needed.
> -sigh-
> That does change things indeed then.
>
> AFAIK the prefetch creates an IMG element but its not attached to the DOM.
>
> - Litty
>
> On Fri, Feb 6, 2009 at 1:03 PM, darkflame  wrote:
>
> > > > "You are thinking of loading 20MB of images into the DHTML DOM of you
> > > > application"
>
> > > > Am I? Does the DOM keep them there even when not displayed?
> > > > These images certainly wouldnt be displayed all at once. 1 or 2 at a
> > > > time at most.
>
> > > I'm not absolutely sure, but I think if you load an image it is
> > > basically attached to a document, whether the browser caches it or
> > > not, and whether it is currently visible of not. You don't control the
> > > browser cache, I mean I don't think you can tell it to conveniently
> > > download all your images and store them neatly on disk until you need
> > > to display them for example.
>
> > ah, pig.
> > I thought that was exactly that prefetch was doing -sigh-
> > I thought it loaded it to ram first, then the browser keeps a copy in
> > its cache for reloading if needed.
> > -sigh-
> > That does change things indeed then.
>
> > > > Again, not at once.
> > > > Surely a staggered download they wouldnt have a problem with?
> > > > Emulating, say, what it would expect from a user browseing DeviantArt?
>
> > > yeah, the staggered download is basically the idea of the maze - each
> > > time you move to next location you've only got one locations worth of
> > > images to fetch. Or if it worked fast enough you could fetch all the
> > > required images for the adjoining locations so they would be ready to
> > > go instantly. It depends entirely on no of image bytes per location.
>
> > Yes, I looks like I'll be switching to a as-you-go-along-it-loads-the-
> > next-rooms approach.
> > Allthough...
>
> > > Point is doing it this way old images are thrown away and can be
> > > garbage collected as you go, so you are not accumulating images in
> > > memory. It's stable. (assuming I'm right about the how this works of
> > > course).
>
> > ...I'm not sure there will be much that can be chucked away in this
> > game.
> > My engine is able to remove items easily enough, but for this game
> > items from the start of the game are still usefull at the end, so
> > theres only a few case's when images can be removed never to be
> > recalled.
>
> > > > ". The point of
> > > > the composite image strip is to fetch several images in one request
> > > > since they come in a single binary file. "
>
> > > > Yes, I understand the point of them, and I think image bundles are a
> > > > great idea.
> > > > (In fact, online in general, theres probably a lot of wasted bandwidth
> > > > used on little UI elements on webpages..like 5kb gifs etc)
> > > > In this specific case though they arnt approperate.
> > > > Not unless I got the server to dynamically splice the images together
> > > > and the client to cut them up.
> > > > But thats beyond the scope of the projects timeframe.
>
> > > This is exactly what the GWT ImageBundle does (and what has been best
> > > practice in web design for years). Annoyingly for you GWT only does
> > > this once per module because Bruce says they can't think of a single
> > > use case for needing separate ImageBundles!  My bet is that if you
> > > just start loading all the images as you are suggesting, you will have
> > > to attach them to the DOM somewhere, so ultimately what you will be
> > > doing is building the entire game at the same time as the player is
> > > trying to play the first locations. So my be

Re: Best image preloading practice?

[gregor]

@Litty: yes, I think you are right, my ignorance. Image.prefetch()
will causes the image to be loaded into browser cache. You then use
the same URL to instantiate an Image object later in code, and
hopefully the image binary will be already downloaded. This old
Mozzilla doc describes the process:

http://devedge-temp.mozilla.org/viewsource/2003/link-prefetching/index_en.html

The doc suggests the behavior darkflame described in OP, namely,
browser is busy downloading all the prefetches it finds in the page.

@darkflame:

>
> b) If I do have to load, say, upto 10 images that have to be seperate,
> is it better to just loop over a list of them prefetching and leave it
> upto the browseror should I put a timer and trigger a load every,
> say, 5 seconds ?
> (or dosnt it make much difference).
>

My reading of the Mozzilla doc is that the browser will notice all the
prefetch tags when it loads the page, and it will then get busy
downloading them. So I have doubts whether where you put the
Image.prefetch(url) in execution logic makes any difference, i.e. you
do not have fine tune programmatic control over prefetch so you can't
code to prefetch first 10, then later trigger prefetching next 10. For
example the Mozzilla doc states "The link tag has to be inside the
head tag to make prefetching work" etc.







> On Feb 6, 9:14 am, Litty Preeth  wrote:
>
> > > > "You are thinking of loading 20MB of images into the DHTML DOM of you
> > > > application"
>
> > > > Am I? Does the DOM keep them there even when not displayed?
> > > > These images certainly wouldnt be displayed all at once. 1 or 2 at a
> > > > time at most.
>
> > > I'm not absolutely sure, but I think if you load an image it is
> > > basically attached to a document, whether the browser caches it or
> > > not, and whether it is currently visible of not. You don't control the
> > > browser cache, I mean I don't think you can tell it to conveniently
> > > download all your images and store them neatly on disk until you need
> > > to display them for example.
>
> > ah, pig.
> > I thought that was exactly that prefetch was doing -sigh-
> > I thought it loaded it to ram first, then the browser keeps a copy in
> > its cache for reloading if needed.
> > -sigh-
> > That does change things indeed then.
>
> > AFAIK the prefetch creates an IMG element but its not attached to the DOM.
>
> > - Litty
>
> > On Fri, Feb 6, 2009 at 1:03 PM, darkflame  wrote:
>
> > > > > "You are thinking of loading 20MB of images into the DHTML DOM of you
> > > > > application"
>
> > > > > Am I? Does the DOM keep them there even when not displayed?
> > > > > These images certainly wouldnt be displayed all at once. 1 or 2 at a
> > > > > time at most.
>
> > > > I'm not absolutely sure, but I think if you load an image it is
> > > > basically attached to a document, whether the browser caches it or
> > > > not, and whether it is currently visible of not. You don't control the
> > > > browser cache, I mean I don't think you can tell it to conveniently
> > > > download all your images and store them neatly on disk until you need
> > > > to display them for example.
>
> > > ah, pig.
> > > I thought that was exactly that prefetch was doing -sigh-
> > > I thought it loaded it to ram first, then the browser keeps a copy in
> > > its cache for reloading if needed.
> > > -sigh-
> > > That does change things indeed then.
>
> > > > > Again, not at once.
> > > > > Surely a staggered download they wouldnt have a problem with?
> > > > > Emulating, say, what it would expect from a user browseing DeviantArt?
>
> > > > yeah, the staggered download is basically the idea of the maze - each
> > > > time you move to next location you've only got one locations worth of
> > > > images to fetch. Or if it worked fast enough you could fetch all the
> > > > required images for the adjoining locations so they would be ready to
> > > > go instantly. It depends entirely on no of image bytes per location.
>
> > > Yes, I looks like I'll be switching to a as-you-go-along-it-loads-the-
> > > next-rooms approach.
> > > Allthough...
>
> > > > Point is doing it this way old images are thrown away and can be
> > > > garbage collected as you go, so you are not accumulating images in
> > > > memory. It's stable. (assuming I'm right about the how this works of
> > > > course).
>
> > > ...I'm not sure there will be much that can be chucked away in this
> > > game.
> > > My engine is able to remove items easily enough, but for this game
> > > items from the start of the game are still usefull at the end, so
> > > theres only a few case's when images can be removed never to be
> > > recalled.
>
> > > > > ". The point of
> > > > > the composite image strip is to fetch several images in one request
> > > > > since they come in a single binary file. "
>
> > > > > Yes, I understand the point of them, and I think image bundles are a
> > > > > great idea.
> > > > > (In fact, online in general, theres probably a lot of wasted bandwidth

Re: Best image preloading practice?

[darkflame]

Well, I know prefetch is working to some extent (at least, in Chrome
and Firefox), as I can watch it prefetching
rather large volumes of images that arnt used in the html at all.
All of those images must have been triggered by the prefetch loop.

Still, I'll read over the Mozzilla doc, maybe things have changed a
little since javascript has been more widely used.


On Feb 6, 3:12 pm, gregor  wrote:
> @Litty: yes, I think you are right, my ignorance. Image.prefetch()
> will causes the image to be loaded into browser cache. You then use
> the same URL to instantiate an Image object later in code, and
> hopefully the image binary will be already downloaded. This old
> Mozzilla doc describes the process:
>
> http://devedge-temp.mozilla.org/viewsource/2003/link-prefetching/inde...
>
> The doc suggests the behavior darkflame described in OP, namely,
> browser is busy downloading all the prefetches it finds in the page.
>
> @darkflame:
>
>
>
> > b) If I do have to load, say, upto 10 images that have to be seperate,
> > is it better to just loop over a list of them prefetching and leave it
> > upto the browseror should I put a timer and trigger a load every,
> > say, 5 seconds ?
> > (or dosnt it make much difference).
>
> My reading of the Mozzilla doc is that the browser will notice all the
> prefetch tags when it loads the page, and it will then get busy
> downloading them. So I have doubts whether where you put the
> Image.prefetch(url) in execution logic makes any difference, i.e. you
> do not have fine tune programmatic control over prefetch so you can't
> code to prefetch first 10, then later trigger prefetching next 10. For
> example the Mozzilla doc states "The link tag has to be inside the
> head tag to make prefetching work" etc.
>
>
>
> > On Feb 6, 9:14 am, Litty Preeth  wrote:
>
> > > > > "You are thinking of loading 20MB of images into the DHTML DOM of you
> > > > > application"
>
> > > > > Am I? Does the DOM keep them there even when not displayed?
> > > > > These images certainly wouldnt be displayed all at once. 1 or 2 at a
> > > > > time at most.
>
> > > > I'm not absolutely sure, but I think if you load an image it is
> > > > basically attached to a document, whether the browser caches it or
> > > > not, and whether it is currently visible of not. You don't control the
> > > > browser cache, I mean I don't think you can tell it to conveniently
> > > > download all your images and store them neatly on disk until you need
> > > > to display them for example.
>
> > > ah, pig.
> > > I thought that was exactly that prefetch was doing -sigh-
> > > I thought it loaded it to ram first, then the browser keeps a copy in
> > > its cache for reloading if needed.
> > > -sigh-
> > > That does change things indeed then.
>
> > > AFAIK the prefetch creates an IMG element but its not attached to the DOM.
>
> > > - Litty
>
> > > On Fri, Feb 6, 2009 at 1:03 PM, darkflame  wrote:
>
> > > > > > "You are thinking of loading 20MB of images into the DHTML DOM of 
> > > > > > you
> > > > > > application"
>
> > > > > > Am I? Does the DOM keep them there even when not displayed?
> > > > > > These images certainly wouldnt be displayed all at once. 1 or 2 at a
> > > > > > time at most.
>
> > > > > I'm not absolutely sure, but I think if you load an image it is
> > > > > basically attached to a document, whether the browser caches it or
> > > > > not, and whether it is currently visible of not. You don't control the
> > > > > browser cache, I mean I don't think you can tell it to conveniently
> > > > > download all your images and store them neatly on disk until you need
> > > > > to display them for example.
>
> > > > ah, pig.
> > > > I thought that was exactly that prefetch was doing -sigh-
> > > > I thought it loaded it to ram first, then the browser keeps a copy in
> > > > its cache for reloading if needed.
> > > > -sigh-
> > > > That does change things indeed then.
>
> > > > > > Again, not at once.
> > > > > > Surely a staggered download they wouldnt have a problem with?
> > > > > > Emulating, say, what it would expect from a user browseing 
> > > > > > DeviantArt?
>
> > > > > yeah, the staggered download is basically the idea of the maze - each
> > > > > time you move to next location you've only got one locations worth of
> > > > > images to fetch. Or if it worked fast enough you could fetch all the
> > > > > required images for the adjoining locations so they would be ready to
> > > > > go instantly. It depends entirely on no of image bytes per location.
>
> > > > Yes, I looks like I'll be switching to a as-you-go-along-it-loads-the-
> > > > next-rooms approach.
> > > > Allthough...
>
> > > > > Point is doing it this way old images are thrown away and can be
> > > > > garbage collected as you go, so you are not accumulating images in
> > > > > memory. It's stable. (assuming I'm right about the how this works of
> > > > > course).
>
> > > > ...I'm not sure there will be much that can be chucked away in this
> > > >

Re: Best image preloading practice?

[davidroe]

I have only skimmed this thread, and I've not looked at the game, but
here is my 2c.

my situation is a little different - I'm not pre-loading images per
se, but I am loading them in the background. I use a hidden panel
(hidden by being positioned off screen rather than display:none) which
I load images onto. each image has a load listener so that I can
process it when it arrives and move it to the appropriate part of the
DOM.

on to your problem.

could you maintain an array of image URLs, load the first image,
attach a load listener and attach it to a hidden panel? when the image
has loaded, repeat the process to load the next one. that way, you
ensure that they only load one at a time (less blocking behaviour in
the browser). once you know an image has been loaded, you are free to
use new Image(url) and know reliably that the image will be loaded
from cache.

HTH,
/dave

On Feb 8, 7:04 am, darkflame  wrote:
> Well, I know prefetch is working to some extent (at least, in Chrome
> and Firefox), as I can watch it prefetching
> rather large volumes of images that arnt used in the html at all.
> All of those images must have been triggered by the prefetch loop.
>
> Still, I'll read over the Mozzilla doc, maybe things have changed a
> little since javascript has been more widely used.
>
> On Feb 6, 3:12 pm, gregor  wrote:
>
> > @Litty: yes, I think you are right, my ignorance. Image.prefetch()
> > will causes the image to be loaded into browser cache. You then use
> > the same URL to instantiate an Image object later in code, and
> > hopefully the image binary will be already downloaded. This old
> > Mozzilla doc describes the process:
>
> >http://devedge-temp.mozilla.org/viewsource/2003/link-prefetching/inde...
>
> > The doc suggests the behavior darkflame described in OP, namely,
> > browser is busy downloading all the prefetches it finds in the page.
>
> > @darkflame:
>
> > > b) If I do have to load, say, upto 10 images that have to be seperate,
> > > is it better to just loop over a list of them prefetching and leave it
> > > upto the browseror should I put a timer and trigger a load every,
> > > say, 5 seconds ?
> > > (or dosnt it make much difference).
>
> > My reading of the Mozzilla doc is that the browser will notice all the
> > prefetch tags when it loads the page, and it will then get busy
> > downloading them. So I have doubts whether where you put the
> > Image.prefetch(url) in execution logic makes any difference, i.e. you
> > do not have fine tune programmatic control over prefetch so you can't
> > code to prefetch first 10, then later trigger prefetching next 10. For
> > example the Mozzilla doc states "The link tag has to be inside the
> > head tag to make prefetching work" etc.
>
> > > On Feb 6, 9:14 am, Litty Preeth  wrote:
>
> > > > > > "You are thinking of loading 20MB of images into the DHTML DOM of 
> > > > > > you
> > > > > > application"
>
> > > > > > Am I? Does the DOM keep them there even when not displayed?
> > > > > > These images certainly wouldnt be displayed all at once. 1 or 2 at a
> > > > > > time at most.
>
> > > > > I'm not absolutely sure, but I think if you load an image it is
> > > > > basically attached to a document, whether the browser caches it or
> > > > > not, and whether it is currently visible of not. You don't control the
> > > > > browser cache, I mean I don't think you can tell it to conveniently
> > > > > download all your images and store them neatly on disk until you need
> > > > > to display them for example.
>
> > > > ah, pig.
> > > > I thought that was exactly that prefetch was doing -sigh-
> > > > I thought it loaded it to ram first, then the browser keeps a copy in
> > > > its cache for reloading if needed.
> > > > -sigh-
> > > > That does change things indeed then.
>
> > > > AFAIK the prefetch creates an IMG element but its not attached to the 
> > > > DOM.
>
> > > > - Litty
>
> > > > On Fri, Feb 6, 2009 at 1:03 PM, darkflame  wrote:
>
> > > > > > > "You are thinking of loading 20MB of images into the DHTML DOM of 
> > > > > > > you
> > > > > > > application"
>
> > > > > > > Am I? Does the DOM keep them there even when not displayed?
> > > > > > > These images certainly wouldnt be displayed all at once. 1 or 2 
> > > > > > > at a
> > > > > > > time at most.
>
> > > > > > I'm not absolutely sure, but I think if you load an image it is
> > > > > > basically attached to a document, whether the browser caches it or
> > > > > > not, and whether it is currently visible of not. You don't control 
> > > > > > the
> > > > > > browser cache, I mean I don't think you can tell it to conveniently
> > > > > > download all your images and store them neatly on disk until you 
> > > > > > need
> > > > > > to display them for example.
>
> > > > > ah, pig.
> > > > > I thought that was exactly that prefetch was doing -sigh-
> > > > > I thought it loaded it to ram first, then the browser keeps a copy in
> > > > > its cache for reloading if needed.
> > > > > -sigh-
> 

Re: Best image preloading practice?

[darkflame]

Thats not a bad idea, it didnt accore to me to simply load it by
positioning it off screena and attaching a listener.

When you hide it offscreen do you specify negative co-ordinates? Or do
you have to put it to the right and stop horizontal scrolling?

I assume checking offset width still works even if its offscreen?

Cheers,
Thomas

On Feb 9, 6:46 am, davidroe  wrote:
> I have only skimmed this thread, and I've not looked at the game, but
> here is my 2c.
>
> my situation is a little different - I'm not pre-loading images per
> se, but I am loading them in the background. I use a hidden panel
> (hidden by being positioned off screen rather than display:none) which
> I load images onto. each image has a load listener so that I can
> process it when it arrives and move it to the appropriate part of the
> DOM.
>
> on to your problem.
>
> could you maintain an array of image URLs, load the first image,
> attach a load listener and attach it to a hidden panel? when the image
> has loaded, repeat the process to load the next one. that way, you
> ensure that they only load one at a time (less blocking behaviour in
> the browser). once you know an image has been loaded, you are free to
> use new Image(url) and know reliably that the image will be loaded
> from cache.
>
> HTH,
> /dave
>
> On Feb 8, 7:04 am, darkflame  wrote:
>
>
>
> > Well, I know prefetch is working to some extent (at least, in Chrome
> > and Firefox), as I can watch it prefetching
> > rather large volumes of images that arnt used in the html at all.
> > All of those images must have been triggered by the prefetch loop.
>
> > Still, I'll read over the Mozzilla doc, maybe things have changed a
> > little since javascript has been more widely used.
>
> > On Feb 6, 3:12 pm, gregor  wrote:
>
> > > @Litty: yes, I think you are right, my ignorance. Image.prefetch()
> > > will causes the image to be loaded into browser cache. You then use
> > > the same URL to instantiate an Image object later in code, and
> > > hopefully the image binary will be already downloaded. This old
> > > Mozzilla doc describes the process:
>
> > >http://devedge-temp.mozilla.org/viewsource/2003/link-prefetching/inde...
>
> > > The doc suggests the behavior darkflame described in OP, namely,
> > > browser is busy downloading all the prefetches it finds in the page.
>
> > > @darkflame:
>
> > > > b) If I do have to load, say, upto 10 images that have to be seperate,
> > > > is it better to just loop over a list of them prefetching and leave it
> > > > upto the browseror should I put a timer and trigger a load every,
> > > > say, 5 seconds ?
> > > > (or dosnt it make much difference).
>
> > > My reading of the Mozzilla doc is that the browser will notice all the
> > > prefetch tags when it loads the page, and it will then get busy
> > > downloading them. So I have doubts whether where you put the
> > > Image.prefetch(url) in execution logic makes any difference, i.e. you
> > > do not have fine tune programmatic control over prefetch so you can't
> > > code to prefetch first 10, then later trigger prefetching next 10. For
> > > example the Mozzilla doc states "The link tag has to be inside the
> > > head tag to make prefetching work" etc.
>
> > > > On Feb 6, 9:14 am, Litty Preeth  wrote:
>
> > > > > > > "You are thinking of loading 20MB of images into the DHTML DOM of 
> > > > > > > you
> > > > > > > application"
>
> > > > > > > Am I? Does the DOM keep them there even when not displayed?
> > > > > > > These images certainly wouldnt be displayed all at once. 1 or 2 
> > > > > > > at a
> > > > > > > time at most.
>
> > > > > > I'm not absolutely sure, but I think if you load an image it is
> > > > > > basically attached to a document, whether the browser caches it or
> > > > > > not, and whether it is currently visible of not. You don't control 
> > > > > > the
> > > > > > browser cache, I mean I don't think you can tell it to conveniently
> > > > > > download all your images and store them neatly on disk until you 
> > > > > > need
> > > > > > to display them for example.
>
> > > > > ah, pig.
> > > > > I thought that was exactly that prefetch was doing -sigh-
> > > > > I thought it loaded it to ram first, then the browser keeps a copy in
> > > > > its cache for reloading if needed.
> > > > > -sigh-
> > > > > That does change things indeed then.
>
> > > > > AFAIK the prefetch creates an IMG element but its not attached to the 
> > > > > DOM.
>
> > > > > - Litty
>
> > > > > On Fri, Feb 6, 2009 at 1:03 PM, darkflame  wrote:
>
> > > > > > > > "You are thinking of loading 20MB of images into the DHTML DOM 
> > > > > > > > of you
> > > > > > > > application"
>
> > > > > > > > Am I? Does the DOM keep them there even when not displayed?
> > > > > > > > These images certainly wouldnt be displayed all at once. 1 or 2 
> > > > > > > > at a
> > > > > > > > time at most.
>
> > > > > > > I'm not absolutely sure, but I think if you load an image it is
> > > > > > > basically attached to a doc

Re: Best image preloading practice?

[davidroe]

.hiddenImagePanel {
position:absolute;
top:-1000px;
left:-1000px;
}

On Feb 9, 1:14 am, darkflame  wrote:
> Thats not a bad idea, it didnt accore to me to simply load it by
> positioning it off screena and attaching a listener.
>
> When you hide it offscreen do you specify negative co-ordinates? Or do
> you have to put it to the right and stop horizontal scrolling?
>
> I assume checking offset width still works even if its offscreen?
>
> Cheers,
> Thomas
>
> On Feb 9, 6:46 am, davidroe  wrote:
>
> > I have only skimmed this thread, and I've not looked at the game, but
> > here is my 2c.
>
> > my situation is a little different - I'm not pre-loading images per
> > se, but I am loading them in the background. I use a hidden panel
> > (hidden by being positioned off screen rather than display:none) which
> > I load images onto. each image has a load listener so that I can
> > process it when it arrives and move it to the appropriate part of the
> > DOM.
>
> > on to your problem.
>
> > could you maintain an array of image URLs, load the first image,
> > attach a load listener and attach it to a hidden panel? when the image
> > has loaded, repeat the process to load the next one. that way, you
> > ensure that they only load one at a time (less blocking behaviour in
> > the browser). once you know an image has been loaded, you are free to
> > use new Image(url) and know reliably that the image will be loaded
> > from cache.
>
> > HTH,
> > /dave
>
> > On Feb 8, 7:04 am, darkflame  wrote:
>
> > > Well, I know prefetch is working to some extent (at least, in Chrome
> > > and Firefox), as I can watch it prefetching
> > > rather large volumes of images that arnt used in the html at all.
> > > All of those images must have been triggered by the prefetch loop.
>
> > > Still, I'll read over the Mozzilla doc, maybe things have changed a
> > > little since javascript has been more widely used.
>
> > > On Feb 6, 3:12 pm, gregor  wrote:
>
> > > > @Litty: yes, I think you are right, my ignorance. Image.prefetch()
> > > > will causes the image to be loaded into browser cache. You then use
> > > > the same URL to instantiate an Image object later in code, and
> > > > hopefully the image binary will be already downloaded. This old
> > > > Mozzilla doc describes the process:
>
> > > >http://devedge-temp.mozilla.org/viewsource/2003/link-prefetching/inde...
>
> > > > The doc suggests the behavior darkflame described in OP, namely,
> > > > browser is busy downloading all the prefetches it finds in the page.
>
> > > > @darkflame:
>
> > > > > b) If I do have to load, say, upto 10 images that have to be seperate,
> > > > > is it better to just loop over a list of them prefetching and leave it
> > > > > upto the browseror should I put a timer and trigger a load every,
> > > > > say, 5 seconds ?
> > > > > (or dosnt it make much difference).
>
> > > > My reading of the Mozzilla doc is that the browser will notice all the
> > > > prefetch tags when it loads the page, and it will then get busy
> > > > downloading them. So I have doubts whether where you put the
> > > > Image.prefetch(url) in execution logic makes any difference, i.e. you
> > > > do not have fine tune programmatic control over prefetch so you can't
> > > > code to prefetch first 10, then later trigger prefetching next 10. For
> > > > example the Mozzilla doc states "The link tag has to be inside the
> > > > head tag to make prefetching work" etc.
>
> > > > > On Feb 6, 9:14 am, Litty Preeth  wrote:
>
> > > > > > > > "You are thinking of loading 20MB of images into the DHTML DOM 
> > > > > > > > of you
> > > > > > > > application"
>
> > > > > > > > Am I? Does the DOM keep them there even when not displayed?
> > > > > > > > These images certainly wouldnt be displayed all at once. 1 or 2 
> > > > > > > > at a
> > > > > > > > time at most.
>
> > > > > > > I'm not absolutely sure, but I think if you load an image it is
> > > > > > > basically attached to a document, whether the browser caches it or
> > > > > > > not, and whether it is currently visible of not. You don't 
> > > > > > > control the
> > > > > > > browser cache, I mean I don't think you can tell it to 
> > > > > > > conveniently
> > > > > > > download all your images and store them neatly on disk until you 
> > > > > > > need
> > > > > > > to display them for example.
>
> > > > > > ah, pig.
> > > > > > I thought that was exactly that prefetch was doing -sigh-
> > > > > > I thought it loaded it to ram first, then the browser keeps a copy 
> > > > > > in
> > > > > > its cache for reloading if needed.
> > > > > > -sigh-
> > > > > > That does change things indeed then.
>
> > > > > > AFAIK the prefetch creates an IMG element but its not attached to 
> > > > > > the DOM.
>
> > > > > > - Litty
>
> > > > > > On Fri, Feb 6, 2009 at 1:03 PM, darkflame  
> > > > > > wrote:
>
> > > > > > > > > "You are thinking of loading 20MB of images into the DHTML 
> > > > > > > > > DOM of you
> > > > > > > > > application"

Re: Best image preloading practice?

[Thomas Wrobel]

Just tried that but it dosnt seem to work :-/
The loading is working fine, but the negative co-ordinates dont seem
to be working.
Firebug shows the style currently attached but has lines though all
the lines in hiddenImagePanel css code.
I havnt actually attached any other styles to the image, so I'm not
sure why this would be, the only style setting is;
LoadThis.setStylePrimaryName("hiddenImagePanel");

However, this isnt a big deal, I just attached the image with;
RootPanel.get().add(LoadThis,-9000,-9000);

And it seems to work fine. (allthough I gota cross check on other browsers)



2009/2/9 davidroe :
>
> .hiddenImagePanel {
>position:absolute;
>top:-1000px;
>left:-1000px;
> }
>
> On Feb 9, 1:14 am, darkflame  wrote:
>> Thats not a bad idea, it didnt accore to me to simply load it by
>> positioning it off screena and attaching a listener.
>>
>> When you hide it offscreen do you specify negative co-ordinates? Or do
>> you have to put it to the right and stop horizontal scrolling?
>>
>> I assume checking offset width still works even if its offscreen?
>>
>> Cheers,
>> Thomas
>>
>> On Feb 9, 6:46 am, davidroe  wrote:
>>
>> > I have only skimmed this thread, and I've not looked at the game, but
>> > here is my 2c.
>>
>> > my situation is a little different - I'm not pre-loading images per
>> > se, but I am loading them in the background. I use a hidden panel
>> > (hidden by being positioned off screen rather than display:none) which
>> > I load images onto. each image has a load listener so that I can
>> > process it when it arrives and move it to the appropriate part of the
>> > DOM.
>>
>> > on to your problem.
>>
>> > could you maintain an array of image URLs, load the first image,
>> > attach a load listener and attach it to a hidden panel? when the image
>> > has loaded, repeat the process to load the next one. that way, you
>> > ensure that they only load one at a time (less blocking behaviour in
>> > the browser). once you know an image has been loaded, you are free to
>> > use new Image(url) and know reliably that the image will be loaded
>> > from cache.
>>
>> > HTH,
>> > /dave
>>
>> > On Feb 8, 7:04 am, darkflame  wrote:
>>
>> > > Well, I know prefetch is working to some extent (at least, in Chrome
>> > > and Firefox), as I can watch it prefetching
>> > > rather large volumes of images that arnt used in the html at all.
>> > > All of those images must have been triggered by the prefetch loop.
>>
>> > > Still, I'll read over the Mozzilla doc, maybe things have changed a
>> > > little since javascript has been more widely used.
>>
>> > > On Feb 6, 3:12 pm, gregor  wrote:
>>
>> > > > @Litty: yes, I think you are right, my ignorance. Image.prefetch()
>> > > > will causes the image to be loaded into browser cache. You then use
>> > > > the same URL to instantiate an Image object later in code, and
>> > > > hopefully the image binary will be already downloaded. This old
>> > > > Mozzilla doc describes the process:
>>
>> > > >http://devedge-temp.mozilla.org/viewsource/2003/link-prefetching/inde...
>>
>> > > > The doc suggests the behavior darkflame described in OP, namely,
>> > > > browser is busy downloading all the prefetches it finds in the page.
>>
>> > > > @darkflame:
>>
>> > > > > b) If I do have to load, say, upto 10 images that have to be 
>> > > > > seperate,
>> > > > > is it better to just loop over a list of them prefetching and leave 
>> > > > > it
>> > > > > upto the browseror should I put a timer and trigger a load every,
>> > > > > say, 5 seconds ?
>> > > > > (or dosnt it make much difference).
>>
>> > > > My reading of the Mozzilla doc is that the browser will notice all the
>> > > > prefetch tags when it loads the page, and it will then get busy
>> > > > downloading them. So I have doubts whether where you put the
>> > > > Image.prefetch(url) in execution logic makes any difference, i.e. you
>> > > > do not have fine tune programmatic control over prefetch so you can't
>> > > > code to prefetch first 10, then later trigger prefetching next 10. For
>> > > > example the Mozzilla doc states "The link tag has to be inside the
>> > > > head tag to make prefetching work" etc.
>>
>> > > > > On Feb 6, 9:14 am, Litty Preeth  wrote:
>>
>> > > > > > > > "You are thinking of loading 20MB of images into the DHTML DOM 
>> > > > > > > > of you
>> > > > > > > > application"
>>
>> > > > > > > > Am I? Does the DOM keep them there even when not displayed?
>> > > > > > > > These images certainly wouldnt be displayed all at once. 1 or 
>> > > > > > > > 2 at a
>> > > > > > > > time at most.
>>
>> > > > > > > I'm not absolutely sure, but I think if you load an image it is
>> > > > > > > basically attached to a document, whether the browser caches it 
>> > > > > > > or
>> > > > > > > not, and whether it is currently visible of not. You don't 
>> > > > > > > control the
>> > > > > > > browser cache, I mean I don't think you can tell it to 
>> > > > > > > convenie

Re: Best image preloading practice?

[lukehashj]

You don't necessarily even need the image to be hidden off screen in
that way.

You could always just set it's display:none and have it exist anywhere
on the DOM - the user won't see it but the browser will still go to
fetch the image.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best image preloading practice?

[Thomas Wrobel]

I did think of that, but I wasnt sure IE would handel it correctly.
I remember theres a few issues with getting IE to fire load-listeners
with data that might already be cached. The workaround was to use
"getOffsetWidth" to check for the load.

Incidently, I'm already seeing *massive* improvement in the loading
system using this one-at-a-time method, and this is before I
implemented the maze techique.
Combined they should reduce the app's apparently loading time a lot.

2009/2/11 lukehashj :
>
> You don't necessarily even need the image to be hidden off screen in
> that way.
>
> You could always just set it's display:none and have it exist anywhere
> on the DOM - the user won't see it but the browser will still go to
> fetch the image.
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best image preloading practice?

[davidroe]

I had thought the same, but I remember that there was a reason for
using this technique. ISTR that at least one browser didn't load
images from the server when attached to a parent whose display is
none. I wouldn't stake my life on this being true, as something else
may have been causing that behaviour, but there you go.

On Feb 11, 2:29 pm, lukehashj  wrote:
> You don't necessarily even need the image to be hidden off screen in
> that way.
>
> You could always just set it's display:none and have it exist anywhere
> on the DOM - the user won't see it but the browser will still go to
> fetch the image.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---