Scrolling not working as intended
Opened this issue · 6 comments
Hello,
thanks for the great addon but we found a problem.
It is not possible to slowly scroll down the grid by dragging the scrollbar.
If you try to slowly scroll the grid by dragging the scrollbar ist stops midway and you have to start dragging again.
This is reproducable with all different implementation types used in your online demo.
When using a normal grid everything works fine.
In which browser did you see that behavior? I noticed that firefox seems to be much slower in rendering the vaadin elements than chrome. I will try to find out the reason for the difference. I tried to debug that problem once, but came to no conclusion. Some guesses I had were
- maybe for some reason RPC calls are slower/more blocking from firefox
- vaadin needs a lot of measurements to calculate the positionings. They already tuned that as much as possible, but it may be that firefox is just worse at caching/determining when to throw away the cache. Here is a link which describes this problem general to Javascript/Browserengines: https://blog.idrsolutions.com/2014/08/beware-javascript-layout-thrashing/
- maybe the rendering speed of firefox is for some reason (see thrashing?) much slower than chrome's and that could lead to "freezing"
But that was only guessing from the javascript debugger output and I could not verify any of these theories yet or trace them back to some source. The thing I could observe was that when firefox sends out a rpc-call it stalls and the calls take much longer to come back. Full-Blown vaadin components require more measurements and more complex rendering and in most cases probably also transport more data.
As it came up now again, I will take up my investigations on that topic again.
Adding firefox profiler dump. What is visible is that the browser fires a lot of events during scrolling which attempt to handle tooltips. The second thing is that it seems to take firefox longer to update innerhtml which is called many many times.
Sorry I forgot to mention that I was using Firefox.
I just tried it in Chrome, there it is a lot better but the grid is still stuttering at drag scroll.
The normal grid demo (which only uses its own implemented Renderers) doesn't have this problem, so debugging this and comparing it to the debug results of your implementations would reveal the location where the unnecessary calls are made?
The stuttering in chrome unfortunately cannot be reduced (you mean the content vanishing?) it depends in the maximum rendering speed of the Browser. If you scroll slower you see it scrolls smoothly up to some speed. The reason vaadin did not use components in the grid by default is that they are too heavy for fast continous scrolls. If you are ok with the vanishing, you probably mean the stops When it loads data. I was thinking about some more intelligent loading mechanism which does not fire rpc calls right away when stopping or delays rendering until scroll speed drops below some value. But I have to see if I can tap into these grid mechanisms and if the idea is feasible at all. The components renderer cannot replace the lightweight renderers, but it gives you the possibility of a tradeoff, especially for grids with lower row counts.
I was thinking about implementing some lightweight renderers too, what is your usecase for the component renderer? What kind of lightweight renderer do you replace with it?
Yes, I was meaning the stops of the scrollbar and than it jumps to the new cursor location.
I just wanted renderers for: Icon, HTML-Text, Date and a way to format custom referenced pojos.
I was searching for some lightweight renderers for that but couldn't find any I could use.
So I thought that with your addon I wouldn't need to implement them myself.
Sorry, no good news yet. Just a short comment regarding my current experiments and findings. The stutter effect in Firefox also appears when the (visual) rendering part is completely replaced by an always-the-same empty box. As soon as elements are added to the hierarchy the effect appears. In the profiler I can see e.g. the setInnerHtml calls for the ComboBox are executed anyway even if the element is not displayed. So maybe it has to do with the DOM changes or with the (vaadin) hierarchy changes caused by the added components. The only approach which allowed smooth moving of the scrollbar was some very nasty violator-pattern code breaking Java encapsulation with Javascript and catching the scroll-actions when a certain scrollspeed was exceeded. The problem then is that the rows stand completely still until the scroll is finished and then jump to the desired location. I implemented some overlay like it was with the old table. By that I prevent adding the elements to the hierarchy during scroll. But I am not really satisfied with the solution. I would not release that as part of the component renderer (if I release it at all), but as an experimental extension. Because of the break of encapsulation it is probable that future Vaadin releases would break that extension, or the extension would break the grid. I will keep that ticket open and continue to search for a solution, but it might take a while (several months) and it is not guaranteed that I can find a feasible solution.