GIF Loading Image While GWT Application Loads

[Nick]

I've created a GWT project and included a div tag with an animated gif
in it. The idea is, while my GWT application loads, you'll see this
image moving because it is included in the static HTML file. When the
onModuleLoad() function is almost done, I remove this div from the
DOM, thus removing the image.

My problem is, the GIF image freezes and doesn't move while my
application is loading. The image only moves if there is a problem in
my app and it never loads.

Is there a way to include a moving image, a GIF, while the onModuleLoad
() function is running? I'm not sure why it is freezing.

I look forward to a creative answer.

Thanks,
Nick

[Vitali Lovich]

Browsers are single threaded.  If it was the case that your onModuleLoad was actually taking a long time, then the browser wouldn't be doing anything else.  If that's the case, then try breaking up your onModuleLoad into several parts & then do:

    enum StartupTask {
          TASK1:
          TASK2:
          TASK3:
    }
DeferredCommand.addCommand(new IncrementalCommand() {
    StartupTask current = StartupTask.TASK1;

    public boolean execute() {
            switch (current) {
                case TASK1:
                      // do my initialization
                      current = TASK2;
                      break;
                case TASK2:
                       // continue intialization
                       current = TASK3:
                case TASK3:
                       // finish initialization
                       current = null;
            }
            return current != null;
    }
});

That's one way to do it.  Or you could add a bunch of Command instances instead of using incremental command.  Any number of ways to do this.  Are you sure though that your onModuleLoad takes a long time?

Try instrumenting it first:

public void onModuleLoad()
{
       long start = System.currentTimeMillis();
       // rest of code
       long elapsed = System.currentTimeMillis() - start;
       Window.alert("Initialization took " + elapsed + " milliseconds");

[Dean S. Jones]

onModuleLoad() the culprit... anytime a significant amount of
JavaScript is run, it uses the single browser thread. That same thread
is
used to run "Animated GIF's", hence they freeze while script is being
run. Breaking up the tasks will only make the GIF animation
"choppy" while waiting for an Async call to return. I found no easy
way around this is GWT.

[Vitali Lovich]

On Sat, Apr 11, 2009 at 4:30 AM, Dean S. Jones <deans...@gmail.com> wrote:

onModuleLoad() the culprit... anytime a significant amount of
JavaScript is run, it uses the single browser thread. That same thread
is
used to run "Animated GIF's", hence they freeze while script is being
run. Breaking up the tasks will only make the GIF animation
"choppy" while waiting for an Async call to return.

What does an async call have to do with this?  That's networking stuff which doesn't apply here.

I said used DeferredCommand with IncrementalCommand which simply keeps appending an event to be processed on the event thread while there's more work to be done.  Make sure that every invocation of your incremental command takes 1/rate where rate is the fps of your gif (split it up further if it's still kinda choppy), & you shouldn't have any stuttering.  Your app might take longer to load, but it'll be more responsive.
 

I found no easy
way around this is GWT.

There is - IncrementalCommand.

[Dean S. Jones]

I'm not saying IncrementalCommand doesn't help, it just breaks up the
JavaScript into smaller units, adding DeferredCommand lets the "GIF
Animation" use the thread while the JS is scheduled to run. Async has
alot to do with it... while waiting for a reply, the browser thread is
free, quiescent, ... the combination of both Incremental and Deferred
can smooth the effect tho.

On Apr 11, 4:42 am, Vitali Lovich <vlov...@gmail.com> wrote:

[Vitali Lovich]

On Sat, Apr 11, 2009 at 4:57 AM, Dean S. Jones <deans...@gmail.com> wrote:

I'm not saying IncrementalCommand doesn't help, it just breaks up the
JavaScript into smaller units, adding DeferredCommand lets the "GIF
Animation" use the thread while the JS is scheduled to run.

Which exactly solves the problem he is having whereby the animation freezes.
 

Async has
alot to do with it... while waiting for a reply, the browser thread is
free, quiescent, ...

right, but nowhere did he mention he was making an RPC call or some other kind of AJAX request.  This is strictly regular Javascript code.
 

the combination of both Incremental and Deferred
can smooth the effect tho.

DeferredCommand is simply a utility to append code to be executed at the end of the current event loop.  It's not about smoothing the effect - it actually will remove any freezes in your animation if you make your incremental steps small enough (you might get like at most 3-6 milliseconds of jitter if you do it right, which you'll never actually see or even be able to measure).
 

[Dean S. Jones]

You are correct, Incremental+Deferred lessens the effect.

In a perverse way, I like to see the freeze. It reminds me that the
browser is processing "something", and I investigate "what" that time
is.

[Vitali Lovich]

But it'll piss off your users to no end for completely hanging their browser.  Unless they use Chrome or Safari (I believe those are currently the only 2 browsers that don't block all tabs if one has runaways JS), the whole browser will lock up too.

[Dean S. Jones]

IE6 is the benchmark - if it doesn't perform there, it's back to the
drawing board.

[Dean S. Jones]

We know IE6 has 2 connections, we can "batch" requests to work around
this....

As far as Firefox and Chrome - We have had to "throttle" simultaneous
requests.

Web Architecture is a weird and fine art ;-)

[Vitali Lovich]

On Sat, Apr 11, 2009 at 6:18 AM, Dean S. Jones <deans...@gmail.com> wrote:

IE6 is the benchmark - if it doesn't perform there, it's back to the
drawing board.

Are you referring to the lock up issue?  It affects IE6 as well, maybe even worse because with IE6 when you hit ctrl+n, it actually does it in a really stupid way such that if one window crashes all of them crash.  so i dunno cause I haven't used IE6 in about 8 years, but it's possible that one of those windows locking up with JS will lock up all of them.

[Vitali Lovich]

On Sat, Apr 11, 2009 at 6:31 AM, Dean S. Jones <deans...@gmail.com> wrote:

We know IE6 has 2 connections, we can "batch" requests to work around
this....

As far as Firefox and Chrome - We have had to "throttle" simultaneous
requests.

Web Architecture is a weird and fine art  ;-)

Generally, I find that there's really no need to make multiple requests at once.  Usually you're only going to have at most 2 connections at any time anyways.  1 connection for background updates (push) + 1 connection to send user actions to the server (if user actions can occur while this connection is in progress, then simply store the info in an array & handle flushing the data in the callback).

But this doesn't, as far as I can see, have anything to do with the original question, which was how to get the GIF to keep animating while he's loading his module.  The solution to that does not have anything to do with making connections - DeferredCommand simply adds things to the event queue (like new Timer(){public void run()}.schedule(1)).  You can add as many of these as you want.

[JoeB]

But what if the delay is due to the time it takes for the JavaScript
to be sent across the network and loaded into the browser (as opposed
to the onModuleLoad function running to completion)? e.g. If the
client becomes large with lots of JavaScript, then it will take more
time to load. Will the animated GIF be animated during that time?

-- Joe

[Vitali Lovich]

All network communication happens in the background.  The Javascript will not begin executing until it is fully downloaded as it would be to difficult to attempt to execute partially downloaded Javascript.  During this time the browser will run as usual, meaning the GIF should be animated.

 

-- Joe

[Nick]

For a simple 'loading' GIF, this is getting too complicated. When the
complexity of the solution begins to make the feature look bad, I
begin to look for an alternative. In this case, a non-moving image or
text would seem the way to go. I appreciate all your expert advice.

Thanks,
Nick

On Apr 11, 7:39 am, Vitali Lovich <vlov...@gmail.com> wrote: