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 <martin.goroste...@gmail.com> 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 > Fiddler2<http://www.fiddler2.com/>session 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 <greg.power...@googlemail.com> 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 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 <greg.power...@googlemail.com> 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 <darkfl...@gmail.com> 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 > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
