GWT module loading progress bar... is it possible?

[Dominik Steiner]

Hi there,

is it possible to implement a progress bar that comes up on loading a
GWT module and indicates the % progress of the loading of that module?

Thanks

Dominik

[Srini Marreddy]

Hi Dominik,
I am not sure if it is possible to show the %progress but for
one of my projects i am working on i add Loading message as described
below.This shows a Loading gif file until the GWT module is loaded.

i) Add a DIV tag with id="Loading" and Add a Loading gif file.I have
used http://www.ajaxload.info/ to generate one
<div id="loading"><img src="loading.gif"/>Loading Please wait..</
div> .

ii) In your module entry point code Hide the Above loading DIV .
Following is the code i have used for this.

com.google.gwt.user.client.Element loading = DOM
.getElementById("loading");
DOM.setInnerHTML(loading, "");
DOM.removeChild(DOM.getElementById("mainBodyPanel"), loading); //
Loading div is child of "mainBodyPanel" in my module

Regards,
Srini



On May 16, 10:50 am, Dominik Steiner

[Dominik Steiner]

Hi Srini,

thanks for the fast reply. Your solution for the loading bar is a good
one. But i'm wondering if there is any possibility to have an accurate
feedback on the % progress of the loading?

Thanks

Dominik

On 16 Mai, 13:53, Srini Marreddy <srmarre...@gmail.com> wrote:
> Hi Dominik,
> I am not sure if it is possible to show the %progress but for
> one of my projects i am working on i add Loading message as described
> below.This shows a Loading gif file until the GWT module is loaded.
>
> i) Add a DIV tag with id="Loading" and Add a Loading gif file.I have

> usedhttp://www.ajaxload.info/ to generate one

[Srini Marreddy]

Hi Domnik,

Sorry I am not sure how to calculate % progess of the
loading. That would be really nice if it is possible to show the
download progress.

-Srini


On May 16, 3:40 pm, Dominik Steiner <Dominik.J.Stei...@googlemail.com>
wrote:

> Hi Srini,
>
> thanks for the fast reply. Your solution for the loading bar is a good
> one. But i'm wondering if there is any possibility to have an accurate
> feedback on the % progress of the loading?
>
> Thanks
>
> Dominik
>
> On 16 Mai, 13:53, Srini Marreddy <srmarre...@gmail.com> wrote:
>
> > Hi Dominik,
> > I am not sure if it is possible to show the %progress but for
> > one of my projects i am working on i add Loading message as described
> > below.This shows a Loading gif file until the GWT module is loaded.
>
> > i) Add a DIV tag with id="Loading" and Add a Loading gif file.I have

> > usedhttp://www.ajaxload.info/to generate one

[Axel Kittenberger]

Well the problem is, I know of no interface the browser provides, that
tells you, how many bytes it has already loaded of any script...

Calculating % is easy after that :-)

Another small challenge would be to embed somewhere the total size of
the script.. but this would be doable with some server-side script,
writing this info into some seperate file.

On May 16, 10:53 pm, Srini Marreddy <srmarre...@gmail.com> wrote:
> Hi Domnik,
>
> Sorry I am not sure how to calculate % progess of the
> loading. That would be really nice if it is possible to show the
> download progress.
>
> -Srini
>
> On May 16, 3:40 pm, Dominik Steiner <Dominik.J.Stei...@googlemail.com>
> wrote:
>
> > Hi Srini,
>
> > thanks for the fast reply. Your solution for the loading bar is a good
> > one. But i'm wondering if there is any possibility to have an accurate
> > feedback on the % progress of the loading?
>
> > Thanks
>
> > Dominik
>
> > On 16 Mai, 13:53, Srini Marreddy <srmarre...@gmail.com> wrote:
>
> > > Hi Dominik,
> > > I am not sure if it is possible to show the %progress but for
> > > one of my projects i am working on i add Loading message as described
> > > below.This shows a Loading gif file until the GWT module is loaded.
>
> > > i) Add a DIV tag with id="Loading" and Add a Loading gif file.I have

> > > usedhttp://www.ajaxload.info/togenerate one

[George Georgovassilis]

Tach Dominik. I don't think it can be very accurately done. The bulk
of GWT code resides in just one file. You could kind of place in every
N-th line (outside a function in the script body) a statement that
updates your progress bar, i.e.
document.getElementById("progress").style.width = "10px",
document.getElementById("progress").style.width = "20px" etc but that
would imply that partially loaded javascript is executed by the
browser, which I have my doubts for. On the other hand keep in mind
that for a properly deployed GWT application the use of a loading
progress meter is limited: the second time a user visits your
application it will be served instantly from cache...

[Carl Scott]

I have seen a widget for this in Ext GWT, but I don't know exactly how
its plumbing works.

I think DeferredCommand could help you, though. I think there's an
IncrementalCommand, which keeps getting called until the job is done.
You could:

1) Calculate total size of what you're loading
2) Throw up the loading screen
3) Have the command update the screen, with the calculated percentage
4) After the IncCommand says it's done, remove loading screen.

Keep in mind that drawing widgets takes time, and even with
DeferredCommand, there is no such thing as threads in javascript so
you just have to wait while things actually draw. But strictly
loading data can be calculated. Hope that helps!

--
Carl Scott
Software Developer, Solertium Corporation

On May 16, 11:50 am, Dominik Steiner

[Axel Kittenberger]

How do you calc the percentage? How do you know the browser has
already say 30kb of 150kb loaded?

[Reinier Zwitserloot]

Browsers do not give access to javascript about how much of a certain
resource has been loaded. Ignore Carl Scott's comment, I think he
doesn't realize we're talking about a progress bar for GWT itself
instead of a generic progress bar.

Javascript in general doesn't run incrementally, so having the actual
GWT data generated by the gwt compiler emit progress bar updates won't
work.

The only way I can think of is:

1. Browser first opens an XML-HTTP connection before actually getting
the gwt datafile in order to receive a cookie from the server. Let's
call it the 'downloadId'.
2. Browser now gets the GWT datafile. Server knows the downloadId as
its sent along in a cookie.
3. Browser, in tandem with the download (by using XML-HTTP requests
for example), opens a second connection to the server to ask how far
the download for 'downloadId' has progressed so far. This number is
somewhat flaky (who knows how much caching has been done by
intermediate routers and proxies?) but in general is a good reflection
of % downloaded. The browser will re-open this query (how far is
download for 'downloadId') every 500 msec or so.


It would work. It's also utterly infeasible:

1. The slower the connection, the more important that loading bar is.
However, the slower the connection, the slower the response will be to
the second request. You'll also be delaying the download because
packets are being 'wasted' giving progress reports.
2. This requires considerable logistics on the server side. GWT is
currently server-agnostic, aside from GWT-RPC. GWT would have to ship
a 'download' library for a big host of web frameworks.
3. In order for the server to measure progress, the download has to
be handled by a servlet (or the equivalent in other web frameworks).
For most web frameworks, letting apache (or the core webserver if it's
not apache) handle big files is way more efficient than letting code
do it. Making all gwt data file downloads be handled by a servlet
probably means your server triples its CPU usage. Just to handle
progress reports. Ick.


A tactic which could be slightly more reasonable is the following:

Right now the gwt data file is just one giant obfuscated JS blob which
is imported via the dynamic creation of a script src= tag. You could
instead grab the data via XML-HTTP, and eval() it. eval() code is slow
code in many JS engines, which is the major roadblock here. However,
you could also hash up the downloaded stuff which has benefits for
e.g. speeding up https (by downloading the core gwt files over http,
enabling caching, but still having security in place by checking the
hash of the downloaded-over-http material with a downloaded-over-https
hash). This XML-HTTP download could be split up into blobs of, say,
20k each, where after each blob has been downloaded, you 1) update the
progress bar, and 2) fire up the request for the next blob.

With some effort you can split on the nearest JS parsing boundary
closest to the next 20k mark, and use multiple script src= tags,
eliminating the slowdown caused by using eval(), though you'd lose the
https speedup thing.

This is possibly feasible (though you'd need to do a little more
research). It's also a boatload of work. You'd have to dive into the
GWT Compiler innards and completely rewrite the gwt bootstrapper.

I doubt any core contributor is going to do it, so if it is going to
be done, you'll have to, and submit a patch.

[Olivier Monaco]

Hi,

Before looking for a way to show download speed, it can be good to
check if the load time comes from download. The load speed of a
JavaScript application comes from the download speed and the parse
speed. For some applications, load time comes from parsing of
JavaScript code and initialization of JS objects. It can be more
interesting to load some chunk of JavaScript at a time, updating the
load progress bar - like that :

1. Download a small piece of JS
2. Parse it (eval or HTML injection)
3. Update progress bar
4. If more JS go to 1

But you can't do it with GWT without changing the compiler.

It's also important to configure correctly the server like using GZip
compression and setting Expires on html, xml, js, css... to reduce
download size (http://developer.yahoo.com/performance/rules.html).

Olivier.

On 17 mai, 15:03, Reinier Zwitserloot <reini...@gmail.com> wrote:
> Browsers do not give access to javascript about how much of a certain
> resource has been loaded. Ignore Carl Scott's comment, I think he
> doesn't realize we're talking about a progress bar for GWT itself
> instead of a generic progress bar.

> ...

[Olivier Monaco]

But doing more HTTP requests increase network latency...

On 17 mai, 23:08, Olivier Monaco <olivier.mon...@free.fr> wrote:
> Hi,
>
> Before looking for a way to show download speed, it can be good to
> check if the load time comes from download. The load speed of a
> JavaScript application comes from the download speed and the parse
> speed. For some applications, load time comes from parsing of
> JavaScript code and initialization of JS objects. It can be more
> interesting to load some chunk of JavaScript at a time, updating the
> load progress bar - like that :

> ...

[Carl Scott]

Apologies, thanks for pointing that out, I did not realize you meant
the actual GWT application.

Srini's reply seems the most feasible, but if you want percentage, I'd
research how browsers do the calculation with download progress.
Really there are only 3 factors to know:

1) Total Size (most important)
2) Download Speed
3) Current Amount Downloaded

A sort of cheap way to accomplish deriving these factors,
respectively:

1) Have the server return the file size or, even cheaper, hardcode the
estimated size (in bytes).
2) ??
3) Calculate this using the download speed, regardless of how much has
actually been downloaded.

If you could figure you that 2nd factor, you could write some simple
javascript that could return the percentage based on these factors.
No, it won't be 100% correct, and maybe the 100% mark will be reached
before it is actually finished or not be reached ... but who really
cares, it will be close enough. I like the idea of the percentage
because the end user isn't sitting and looking at a static screen.
The method outlined above could at least get you close to the finish
line.

Now, you CAN accomplish #2 with PHP I know for a fact, but I don't
know if that will help you in this case as it actually does take a
small bit of processing time, as you must hit the server. For those
people who actually care about speed, as typically, most people's GWT
apps will load quickly anyway, the extra hit is just that much more of
a wait.

Hope that helps this time!

--
Carl Scott
Software Developer, Solertium Corporation

> > > > Dominik- Hide quoted text -
>
> - Show quoted text -

[Ian Bambury]

It all seems like shedload of work.

 

In the past, I have used a 'Loading' message in the HTML and broken the app onModule Load into chunks of work chained together with deferredcommands and put out messages as things happen, so the user gets:

 

Loading

Configuring Menu

Building Home Page

 

or whatever

 

It still seems like a good compromise to me.

 

Ian

http://examples.roughian.com

[jhulford]

It's interesting this discussion coming up now, since the good folks
at gmail have actually literally just implemented the loading progress
bar Dominik is asking about. It shows after login and before the
gmail application loads. Not real clue how they've done it though.

[George Georgovassilis]

I think they implemented a progress bar for something, but if you trace
the loading with firebug it seemt that it covers only a small portion of
the loading process - probably counting modules. Last, don't forget that
gmail isn't written with GWT thus some of the restrictions (monolithic
code module) may not apply there.

[gregor]

I noticed that too. I don't thinbk they actually use GWT for Gmail,
but in GWT terms, how about this for how they do it:

1) start the progress bar in onModuleLoad()
2) dispatch RPC to get latest inbox pagefull.
3) build outer container widgets but keep hidden - give the progress
bar a little nudge for this
4) in onSuccess() from inbox RPC, count messages returned.
5) build inbox message list and backing message widgets one at a time
- update progress bar against counter accordingly
6) on completion set outer container widget to visible and kill
progress bar

It looks to me like they get the message bodies at the same time as
the list as the messages open so fast - hence progress bar and short
wait.

regards
grergor

[Axel Kittenberger]

When onModuleLoad() is executed, the big part of loading your GWT
application is already done. On a slow connection this might result
for example in a 55 seconds wait (to load the big javascript file),
than the progress bar popping up, going from 0 to 100% in 2
seconds...wow. Imagine how this feels for the user :/

[George Georgovassilis]

It seems we must have this futile discussion just for the sake of it, so I'll build on Reiniers proposal:

1. Create a small stub which loads very quickly
2. in there create an iframe
3. point it to an _escaped_ (in the sence of not executable) resource which contains the whole javascript.
4. In your stub you hardcoded the size of the escaped javascript
5. Most browsers will allow you to query the iframe content as it loads incrementally (polling). This you'll use to know how much of your javascript loaded in combination with the pre-determined total size of the script (see step 4)
6. Get the escaped content of the iframe, un-escape it and eval/insert as script/dom/whatever it to make it run

[Axel Kittenberger]

At least you build on someones proposal who has a a clue what is
possible and what isn't :-) (which isn't true for some of the
"proposals" here).

Well I've seen lazyloading on the Roadmap of GWT (a Tier 2 milestone),
once we are there this whole loading percentage stuff will likely get
futile eitherway, or much more easy to implement, as "lazyloading"
most of your stuff at beginning.

On May 19, 3:28 pm, "George Georgovassilis"

[Antonio Leonforte]

Hi George,
did you actually implement the solution you proposed, or is it just an
idea you are going to test?
Would you mind sharing some more on that ?
Thanks.
Antonio.

On May 19, 3:28 pm, "George Georgovassilis"
<g.georgovassi...@gmail.com> wrote:

[George Georgovassilis]

Heaven no! I think that a progress bar for the loadstatus is a complete
overkill that does not add any useful feedback (how many of your desktop
applications have a load progress bar? that's right, just eclipse. And?
Does it make you feel empowered? Informed? In control of the IDE?). If
at all it is an interesting technical challenge and the only useful
feadback is that the connection to the server has not stalled and the
application is indeed being loaded.

[Reinier Zwitserloot]

Just in case it wasn't obvious, I'm with George here. The suggestion
made by Srini, to just have an animated GIF, or even just a
'loading...' message that you hide in your EntryPoint, should do.

On May 19, 9:07 pm, George Georgovassilis <g.georgovassi...@gmail.com>

[Chii]

haha thats great! it's funny if the loading status bar costed the user
load time because it took so much effort to implement!

I say it would be better to spend the effort in implementing better,
faster app than to make a load status bar showing how slow the app can
load.

On May 20, 5:07 am, George Georgovassilis <g.georgovassi...@gmail.com>
wrote: