#427449 - Scrolling issues when moving tasks in project schedules.

[blackmambahk]

Assigned To: Open Development See attached @ 1:05 for scrolling issue when dragging a task in the new project schedule. The client reports they have to drag a task by fits and starts to get it where they want in the project schedule.

Assigned To: Chris Gorske So a few things here:

1. Quickly jumps through the schedule when you try to drag a task

2. If you duplicate a task at the bottom of the schedule it will automatically put you in the middle of the schedule someplace so you have to scroll back down to the bottom to see the duplicated task.

3. If you insert a task below to the very bottom, it will add it but you can't see it, then if you try to scroll down it jumps you back up to the top of the schedule instead of the bottom and then you have to scroll to the bottom again.

[blackmambahk]

General problem with scrolling is.... We had the best scrolling 18 months ago. Version1 worked flawlessly, fast, smooth, accurate but users complained over cosmetic issue of displaying white when scrolling as browser couldn't render fast enough, this was also why most grids are none virtual (as non-virtual grids always render much slower than a virtual grid and use more memory) and it was decided we had to fix that problem so....

Version2 , pretty good scrolling still fast, accurate, though not as smooth as we needed to force rows to align to viewport but reduced the cosmetic issue from white every time you scrolled to grey at the bottom of the grid.

But users complained over the cosmetics again so it was decided we had to fix that issue so...

Version3 only solution left, slow down scrolling so the browser can always render by abandoning native scrolling and making our own scrollbars, makes scrolling jerky, and trying to figure out where the bottom is, is very error prone. BUT the cosmetic issue of white and grey was resolved.

So we have gone from cosmetic issues to functional issues... the end result were known before we started coding, the problem would be fixed but would result in worse scrolling.

[blackmambahk]

So the answer is go back to Version1 - that was by far the best scrolling, then fix the cosmetic issue as far as possible within Version 1 then say this is what you have to accept we can't live with with broken scrolling just to fix cosmetic issue.

[blackmambahk]

1. reverted to native vertical scroll.
2. forced synchronous reflow during render to eliminate white when scrolling.
3. Track height of all rows in the source array, use optimistic prediction, all rows are 31px high unless discovered otherwise on rendering, assume row heights once known do not change unless discovered otherwise on rendering.
4. use ResizeObserver to track row height changes after rendering

Optimizations:

1. do not remove cached rows instead set to display none
2. use transform to position rows and set contains to layout to reduce reflows

Result is very successful, smooth scrolling, accurate, all known issues are resolved

[blackmambahk]

Still to do: Switch horizontal scroll to native, use sticky or fixed(IE11) for locked columns

[blackmambahk]

Note: Polyfill for Array.find was needed.

We need a side project to switch to using https://polyfill.io. One package for IE11 one package for everything else.