> > > "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 <[email protected]> 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 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
