3 ms·

> I always assumed mega-large scrolling just used an "arbitrarily large" size, and every time there was a large scroll event Moving things, even with "transfor

> I always assumed mega-large scrolling just used an "arbitrarily large" size, and every time there was a large scroll event Moving things, even with "transform: translate()", during an "onscroll" event has really bad performance and will always show some level of lag. Using the massively optimised bowser scrolling gives a much smoother user experience. What you do with the virtualised scrolling is limit the number of DOM nodes, and where possible recycle them during the scroll. But they are "absolutely" positioned within the scrolling area. So yes, you could potentially go taller by manually moving elements within an arbitrarily large scroll view, the ux will be frankly quite crap.

crazygringo 4y ago
But for virtualized scrolling, the content you're scrolling to doesn't even exist before you scroll to it. There is no moving of things, so I don't understand what you're saying.
- samwillis 4y ago
  If the height of the scroll area doesn't equal the height of an item X the number of items, you will have to change the offset position of each element within the scroll area on each scroll event. That will lag behind the scroll. To put it another way, if the total height of all items is greater than the height of scroll view, as you scroll from top to bottom the items need to move through the scroll view faster than than the scrolling element. To do that the items need to be moved on each "onscroll" event, even if you only drawing the small fraction of them that are currently visible.
  - crazygringo 4y ago
    Sure but there's no way around that. That's the whole point of virtualized scrolling. With virtual scrolling there's always going to be a lag in displaying. But it's also infinitesimal so it's fine. Also if you're just scrolling by tiny amounts (with trackpad or scroll wheel) then the virtualization doesn't matter, you just add new rows as needed while leaving everything in place. It won't precisely line up with the scroll bar position but the difference will be infinitesimally small, and then you can fix it once scrolling ends.

crazygringo 4y ago

But for virtualized scrolling, the content you're scrolling to doesn't even exist before you scroll to it. There is no moving of things, so I don't understand what you're saying.

samwillis 4y ago
If the height of the scroll area doesn't equal the height of an item X the number of items, you will have to change the offset position of each element within the scroll area on each scroll event. That will lag behind the scroll. To put it another way, if the total height of all items is greater than the height of scroll view, as you scroll from top to bottom the items need to move through the scroll view faster than than the scrolling element. To do that the items need to be moved on each "onscroll" event, even if you only drawing the small fraction of them that are currently visible.
- crazygringo 4y ago
  Sure but there's no way around that. That's the whole point of virtualized scrolling. With virtual scrolling there's always going to be a lag in displaying. But it's also infinitesimal so it's fine. Also if you're just scrolling by tiny amounts (with trackpad or scroll wheel) then the virtualization doesn't matter, you just add new rows as needed while leaving everything in place. It won't precisely line up with the scroll bar position but the difference will be infinitesimally small, and then you can fix it once scrolling ends.