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 <[email protected]>:
>
> .hiddenImagePanel {
> position:absolute;
> top:-1000px;
> left:-1000px;
> }
>
> On Feb 9, 1:14 am, darkflame <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 browser....or 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 <[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.
>>
>> > > > > > 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
>>
>> ...
>>
>> 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 [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
-~----------~----~----~----~------~----~------~--~---
