Proposal: a native solution for virtual scrolling

[andyearnshaw]

This is something that I've proposed as a CSSOM feature, but @annevk suggested I also raise an issue here to widen the discussion. I have a gist detailing the CSSOM proposal.

In brief, virtual scrolling is a feature of very long lists, grids and some other components. You would usually implement it using a custom scrollbar, or using some boilerplate HTML, CSS and JS to hold an element in place and get native scrollbars with the desired scrolling area. The problem with the former is that the experience isn't consistent with native scrollbars and things like touch/momentum scrolling have to be implemented from scratch. The main issue with the native scrollbars approach is that browsers have a limit on the largest size/scroll size a single element can have. A proper solution for virtual scrolling could potentially see scroll sizes of up to Number.MAX_SAFE_INTEGER.

Anne's comment was that there are some elements that scrollbars wouldn't make sense on. He's right, of course, so maybe this could be a feature for Shadow DOM instead (so that you could only have virtual scrolling on the same subset of elements that can have shadow trees). Regardless, it would be great to get some more discussion going and generate some interest in finding a solution and moving forward.

[domenic]

Have you seen https://github.com/valdrinkoshi/virtual-scroller, and/or https://www.youtube.com/watch?v=UtD41bn6kJ0? The Chrome team is currently exploring and prototyping this space pretty actively, and would love your thoughts :)

[andyearnshaw]

Thanks @domenic, it's great to hear that Chrome are actively exploring this problem!

@daKmoR pointed me in the direction of virtual-scroller on Friday, and I've just finished watching the Chrome Dev Summit video for it. It's very interesting stuff, I had a similar idea for abstracting the virtual scrolling part of our grid component, which has some unfortunate coupling in areas like scrolling. At Anaplan, we're using a similar technique for our grid component that scrolls on both axes, with some elements that are fixed on one axis but not on the other. Some of our users have millions of rows/columns of data for the grid and, at the moment, it uses custom overlay scrollbars that look a bit like the macOS ones.

From my (admittedly not as in-depth as I would have liked to have time for) look over virtual-scroller, it doesn't seem like it covers the use cases we have. That's fine, though, it's a high-level solution and it's not going to cover all the use cases. It does look like a good solution for our virtual tree component, however. Since virtual-scroller is proposed as part of the layered API, I feel like there needs to be a proper low-level solution for virtual scrolling to meet one of the layered API's goals:

They stay layered on top of low-level features, never getting access to new capabilities unavailable to web developers

As my CSSOM proposal explains, and @valdrinkoshi mentioned in a comment for virtual-scroller, browsers have a maximum for scroll widths and heights of elements, as low as 1.5 million pixels in Edge/IE 11, 17.5 million in Firefox and 32.5 million in Chrome. This makes it really awkward to handle millions of rows or columns, it's actually impossible without using the custom scrollbars or sacrificing scroll accuracy.

I joined Anaplan in October, sadly none of our components are open source, otherwise someone from the company might have already been involved in the infinite list study group's discussions. I'll be sure to use this case as an argument going forward if I ever get the chance to push an open source agenda :)

[domenic]

@andyearnshaw I'm kind of unclear what you're asking for. It seems like your main complaint is that some browsers have limits on scrollbar height that are lower than you'd like. That doesn't seem like a low-level primitive or API to me; it's just a limit you'd like lifted, similar to various other unspecified, browser-specific limits on the platform such as maximum string size, amount of memory used, etc. I think you'd be best served, if that is your real goal, by filing issues on browsers explaining how it'd be helpful for you to see that limit lifted.

The virtual scroller prototype so far is entirely layered on top of low-level features, and uses no magic capabilities unavailable to web developers, so it's unclear in what way you see it failing to meet its goals.

[andyearnshaw]

@domenic I apologise, I thought my CSSOM proposal made it clear what I was asking for. I even discussed the browser scroll height limits in the FAQ section of my gist. I find it hard to believe that those limits are there for no reason and can simply be lifted. Even if that were the case, virtual scrolling in this way requires unnecessary boilerplate and hoop-jumping. It is essentially a hack to do something that is otherwise not possible. What I'm asking for, is a simple and purpose-built API that enables virtual scrolling.

The virtual scroller prototype so far is entirely layered on top of low-level features, and uses no magic capabilities unavailable to web developers, so it's unclear in what way you see it failing to meet its goals.

Do you mean to say that std:virtual-scroller would be bound by the same scroll height/width limits imposed by browsers, and wouldn't be optimised to work off of low level scrollbar APIs? If that's the case, then I stand corrected, but that seems like all the more reason to come up with something better that virtual-scroller can build on top of.

[domenic]

Yes, std:virtual-scroller will not be able to exceed the scroll limits of the browser (the same for its memory limits, or string size limits, or DOM tree depth limits, ...). Again, I do suggest if there are any limits you find constraining, scroll-related or otherwise, you file bugs on the relevant browsers :).

[andyearnshaw]

So here's the response I got back from one of the Google layout devs:

Realistically we can't increase the max size without severely regressing memory usage across the board.
The fact that roughly the same limit applies to multiple implementations reinforces this tradeoff.

I suspected as much. So it looks like this problem can't be solved simply by requesting that all browsers lift their constraints on maximum element size. It would be great if we could come up with a proper solution.

[domenic]

I'm happy to discuss with my colleagues; I think your confirmation bias in favor of making everyone implement a new API is too strong here.

[andyearnshaw]

I'm happy to discuss with my colleagues

And I appreciate that, thank you.

I think your confirmation bias in favor of making everyone implement a new API is too strong here.

I feel that you're being somewhat disrespectful here. Yes, I proposed a new API, because virtual scrolling is used widely on the web and I feel that making it a first-class feature is a good idea, but all I really wanted was to start a discussion around it and see if others also felt it was a good idea. Maybe it is confirmation bias—I too think it un-coincidental that all browser vendors independently arrive at element size limits—, but it's nothing to do with "making everyone implement a new API", all I'm looking for is a way forward. It's true, I would much prefer one that doesn't involve kicking the can down the road, which I feel increasing maximum sizes is. Maybe this issue is too obscure for you to take the time to discuss why you feel it doesn't require a new API but, in any case, a bit of professional courtesy would be nice.

[andyearnshaw]

A quick progress update on the browser bug trackers. Both Chromium and Firefox devs have indicated that increasing the maximum sizes for elements would be a very large change.

Bokan from the Chromium team responded with:

I'm pessimistic we can do anything with native scrollers without such an API or a major change in the engine. As eae@ alluded to, the limitation comes from the fact that we store our layout object sizes in fixed-precision, 32-bit numbers. At the far end of the spectrum, we could allow content as large as ~4 billion px but we need to save some bits for sub-pixel precision from high density screens and zooming cases so that's where the trade off comes from. IMHO, screen density and zooming is something that affects all pages whereas content larger than 33M pixels is a niche use case so I don't think we'd want to sacrifice bits for additional content size. The alternative would be using 64bit numbers but that'd have a major impact on memory usage.

@chrishtr suggested Display Locking API might provide a solution, but it turned out to be unfeasible for our use case (issue link).

https://bugs.chromium.org/p/chromium/issues/detail?id=932109
https://bugzilla.mozilla.org/show_bug.cgi?id=1527883

I'm still keen to try and move the discussion towards a proposal or solution. I'll try and draw the attention of the developers of the virtualisation libraries I listed above.

[Gaubee]

The alternative would be using 64bit numbers but that'd have a major impact on memory usage.

I don't think it's necessary to use 64-bit numbers, which is not a complete solution to the problem idea.
It is well known that 64-bit numbers are simply two 32-bit numbers combined.
So why not just go ahead and do it that way?

ele.addEvent('scroll', event=>{
  // default = 0n
  ele.scrollTopHeight
  const bigScrollTop = ele.scrollTopHeight << 32n + BigInt(event.scrollTop);
});

It's also easy to implement polyfill, isn't it?