I am using Vaadin push technology, and I want that after a web page is loaded and shown to a user, there will be a heavy chart which will be loaded in the background such that user won’t notice it. Currently, I put the code responsible for the chart calculation and rendering into Vaadin push code element (inside
ui.access -method of a thread). But the behavior I encounter is that when the chart starts to load the whole web page is locked and it is not possible to type nor scroll.
Is it really the way Vaadin push is designed? I.e. the whole UI is being locked instead of the single element which I want to update, or have I possibly coded it in a wrong way?
Is your chart heavy on the server or on the client side?
Using a background thread + ui.access will help with the server side part and push will send the update when server processing is done.
If rendering of the chart in the browser takes a long time and it is all done in one go, the web browser will not handle any scroll/type events until the rendering is done (Javascript is single threaded).
The calculation is done on the server side, and it is the one which is heavy.
Still, I am wondering what it is that takes so much time on the client side - response processing, javascript-calculations, processing of the chart, css recalculation, etc.? When the response arrives to a client with chart datapoints it take almoust two seconds to refresh during which user actions are blocked. Is there any way to optimize this step?
Try looking at the debug window (add ?debug to the url) or the browser console and it might give you some hint. Otherwise, the timeline tab in the Chrome inspector might also tell you what’s happening.
Thanks Artur! I got more detailed information. Still, in my opinion debugger is not very informative.
I have 5 Vaadin pie charts, each has 4-10 colors (series). When push actions happens it takes about 3,5 seconds on IE to render the update. As you can see from Vaadin debugger output:
“17535mshandleUIDLMessage: 447 ms
17536msStarting layout phase
17573msMeasured 9 non connector elements
17764msPass 1 measured 326 elements, fired 4 listeners and did 10 layouts.
17999msPass 2 measured 84 elements, fired 0 listeners and did 1 layouts.
18223msPass 3 measured 2 elements, fired 0 listeners and did 1 layouts.
18232msPass 4 measured 6 elements, fired 1 listeners and did 0 layouts.
18291msDid overflow fix for 3 elements
18348msPass 5 measured 4 elements, fired 0 listeners and did 0 layouts.
18349msNo more changes in pass 6
18577msTotal layout phase time: 1041ms
18578ms * Dumping state changes to the console
18578msUIDL: undefined
18771ms Processing time was 1686ms for 31425 characters of JSON
18771msReferenced paintables: 590
18772msStarting layout phase
18787msMeasured 9 non connector elements
18797msPass 1 measured 3 elements, fired 0 listeners and did 1 layouts.
19033msPass 2 measured 12 elements, fired 0 listeners and did 1 layouts.
19272msPass 3 measured 2 elements, fired 0 listeners and did 1 layouts.
19282msPass 4 measured 6 elements, fired 1 listeners and did 0 layouts.
19343msDid overflow fix for 3 elements
19404msPass 5 measured 4 elements, fired 0 listeners and did 0 layouts.
19405msNo more changes in pass 6
19406msTotal layout phase time: 634ms”
the biggest portions of time spent on are “Processing … characters of JSON” and “Total layout phase time”. I expect that the JSON process time cannot be optimized as it is the time spend on parsing a received message. Do you agree? What about “Total layout time”, is their any way to reduce it?
Processing time was 1686ms for 31425 characters of JSON
This tells that the full processing time (parsing JSON, handling JSON, sending events, updating DOM, doing layout) took 1686ms
This is divided into two parts:
handleUIDLMessage: 447 ms (parsing JSON, handling JSON, sending events, updating DOM)
Total layout phase time: 1041ms (doing layout)
In this case it seems that the layout time is clearly larger than the actualy update time. The time is related to the number of components you have on screen (326 elements are measured). One way to improve things might be to remove unnecessary layouts etc if there are such.
Also IE is slower than other browsers so try Chrome or Firefox to see if there is a significant difference.
Another approach could be to push one chart at a time instead of multiple charts at once. Then the browser would process only one chart, become responsive, process the next one, and so on. This might feel faster for the user.