Important Notice - Forums is archived

To simplify things and help our users to be more productive, we have archived the current forum and focus our efforts on helping developers on Stack Overflow. You can post new questions on Stack Overflow or join our Discord channel.

Product icon

Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.

Eliminating subsequent UI requests before the current one is handled

Saulius Narkevicius
1 decade ago Jan 13, 2011 10:21am
Tomas Vala
1 decade ago Jan 17, 2011 7:47pm
David Wall
1 decade ago Jan 17, 2011 11:45pm
Tomas Vala
1 decade ago Jan 18, 2011 2:16pm
David Wall
1 decade ago Jan 18, 2011 5:03pm
Jouni Koivuviita
1 decade ago Jan 20, 2011 8:17am

David Wall:

Tomas Vala: Some comments:
1. Have never went deep enough to analyze details on how is loading-indicator started/stoped under the hood of Vaadin. It just works well for me as it is for given user-case.
2. According to my experience loading-indicator stays on until all of the stages below are finished:
a) browser sends request and waits for server response (during that animation is shown)
b) browser receives complete servlet response (at that point animated gif stops animation - browser is busy)
c) browser makes DOM changes and redraws the page (at that point indiciator disappears)

B and C are strongly browser dependant. Easily visible in IE/FF and almost non perceivable in Chrome and Opera as JS execution is damn fast in those.

Yeah, even that monstrous view loads in about 1 second on Chrome and Opera and even Safari, while IE and FF were slow. Oddly, I even saw Safair show the loading indicator as expected on the first load that did take a bit, but when I switched to other views and then returned, it was too fast to see any such loading.

Using Firebug, I can see that when I click on the row in the Table that triggers the Form to be populated, the POST UIDL took 182ms with 45.3KB of data. I can see all of those select box data in there (sadly, there are only about 5 different types of select boxes, just 10 usage scenarios where they repeated, so they all have the same "choices" in the drop downs, but there's no way to define just one and use it in 5 places).

That seems to match up with my servlet trace since onRequestStart() is called at 48.774 (time is seconds.msec) and onRequestEnds() is called 48.953 for an elapsed time of 179ms (since I'm testing on my PC there's no real network time). This is then followed by 4 GETs for PNGs all in the 1-4 ms range, with the total time being 3.29 seconds.

Firebug must interfere, too, since when I do it again, the POST UIDL takes on 61ms.

But I simply do not see the busy indicator. But if I put my code into debug, then the busy comes on, turns yellow, then turns red. And when I release it then, it seems that the red indicator stops spinning but does appear to stay on the screen until FF draws the view. But without debug, I don't the indicators at all (or very briefly), yet the view takes 3 seconds to appear and the servlet communications is done fairly quickly.

Got me!

Trying to clear this up a bit.

You got it mostly right, but one crucial aspect of browsers' inner workings was not mentioned: the browser runs everything in one thread, including JS computation, DOM manipulation and rendering.

So when the browser is doing JS computation / manipulating the DOM, it won't do any rendering, and hence the view does not update. That includes updating animated GIF's as well as every other pixel on the screen. The browsers usually optimize the rendering so that it happens only after all JS computation and DOM manipulation is done.

So the flow of things after a click on a button is more like this:

1. Click

2. The Vaadin client sends a request to the servlet, and triggers a timeout for the loading indicator to show (300ms, so it won't flicker for each quick update, only for longer requests).

3 a. If the request ends before the timeout, the Vaadin client hides the loading indicator (clears the timeout), and begins to render the changes. If the changes are huge, the rendering will take many seconds, and the view will remain static during the rendering and nothing else is done during that time (no events prosessed, since the event loop also runs within the same thread). You can break up that one thread with some JS commands (alert window etc. / setTimeout, anything that is asynchronous), but usually just ends up slowing the rendering since the browser can't do all the possible optimizations (batching DOM updates etc.).

3 b. If the request takes more time to end (long operation on the server), the client only waits and is free to update the view, and hence you see the spinning loading indicator. And triggering a debug breakpoint during development from your IDE is the same thing as a long request from the browsers point of view.

3 b cont. When the request finishes, the loading indicator is hidden right away, but since there are other updates to the view right after that (the UIDL response, which might be huge) the view won't update before all the changes have been made to the DOM/view. So the spinner is visible for the whole rendering time, but won't spin.

Hope this clears things up a bit.

David Wall
1 decade ago Jan 20, 2011 5:01pm
Jouni Koivuviita
1 decade ago Jan 21, 2011 9:20am
Luis Olortegui
6 years ago Dec 15, 2016 7:45pm