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 <[email protected]> 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 designed to deal with 20MB documents (big e.g. PDF's are downloaded into viewer plug-ins etc). Would you serve a single 20MB static HTML page? Most people consider a 1MB javacript file to be big. I'm not sure what the practical limits really are for the different browsers, and it probably also depends to some extent on what else they have running in other browser tabs. Personally I would avoid this approach, it doesn't feel right at all. > 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. You can only download one binary file per http request. Remember there are security restrictions in place around this since binaries are dangerous things so you are limited in what you can do in a straight AJAX web app (you need an applet or flex to escape from these). Consequently browsers control binary file download with a view to enabling image files to be fetched easily enough, but other file types require user confirmation for what to do. It's this security issue and how the browsers deal with it that you are running up against. 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. If you leave it to the browser, it makes one Http call per image and you cannot guarantee the order they will be fetched. If you do it yourself (using file download servlet), you also get one binary file per request, but you can chain calls in a specific order. The point of the composite image strip is to fetch several images in one request since they come in a single binary file. > > > Cheers, > Darkflame > > On Feb 4, 7:51 pm, gregor <[email protected]> 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 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 <img> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [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 -~----------~----~----~----~------~----~------~--~---
