Re: [w3c/webcomponents] Proposal: a native solution for virtual scrolling (#791)

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://github.com/WICG/display-locking/issues/49)).

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/791#issuecomment-480804459