Rendering on scroll should maybe be quicker

[mwoc]

In IE11, the behaviour of knockout.list seems slightly less responsive than on Firefox and Chrome. I've done some comparison of how these browsers use knockout.list and found the following:

renderViewPort call rate:

IE11, Chrome:
When using regular scrolling, the renderViewPort calls are 100ms - 430ms apart and all come from the renderTimer, none from renderInterval

Firefox:
Almost all renderViewPort calls come from renderInterval and are 380ms - 390ms apart.

Scroll behaviour:

Firefox, IE11:
Scroll continues after mouse wheel has stopped rotating

Chrome:
Scroll stops immediately when mouse wheel stops rotating

Suggestions:

IE11 and Chrome seem to spit out more scroll events per second than Firefox, so the renderInterval code path is almost never used. Decreasing the renderInterval timeout to 200ms gives a mix of interval and timer calls in Chrome, IE11, but still only interval calls in Firefox, but it gives a smoother experience in IE11.

Would it be ok to decrease the renderInterval timeout to 200ms ?

[sunesimonsen]

Hi Maarten, thanks for the investigation.

Unless there is an error in the code more scroll events shouldn't trigger an increased number of rendering.

The idea is as follows:

• A scroll events queue a rendering
• If a renderTimer is already started, it will be restarted; otherwise a new renderTimer will be started
• The renderInterval timer is started if not already running
• If no scroll events happens in 100ms the view port is rendered and the renderTimer and renderInterval are cleared

This means that as long there are scroll events arriving, the renderTimer is restarted and the renderInterval will therefore keep running and render the viewport regularly until scroll events stop arriving.

So I don't think changing the renderInterval to 200ms will help, it will just increase how often the viewport is re-rendered while scrolling.

[mwoc]

Hi Sune,

It seems I might have thought wrong about the code - it's more likely that renderInterval gets called if the amount of scroll events decreases.
Imagine the browser sending one every 150ms, while we have a setTimeout for 100ms. This would always trigger renderTimer and never renderInterval.
However if it sends a scroll event every 40ms (anything lower than 100ms really), the renderInterval would be used exclusively as renderTimer never hits its timeout.

The main problem I'm seeing is with the initial renderViewport, when one just starts to scroll. In IE11, this immediately shows a white (non-rendered area) which is first filled at the first renderInterval completion (400ms), which is a bit too slow to my taste. Probably that's why I came up with 200ms for renderInterval.

A better solution might be to immediately call renderViewport if queueRendering is called AND renderTimer is null, or to render some extra tiles just before and after the viewport. What do you think?

[sunesimonsen]

Is it okay to postpone the discussion till I'm back on work Monday, or is it something that needs to be solved right now? The reason I ask is that I think it is easier to discuss a solution in person.

[mwoc]

It sure is, let's take it up then

[sunesimonsen]

Great!

[mwoc]

Seems we haven't picked up on this yet, but still might be relevant.