Re: Scroll linked effects for a VirtualScroll application

Hi Felix,

I don't think CompositorWorker will help with this situation, because you
need to move around DOM elements on scroll as they get recycled. I think
the best solution available in terms of current web APIs is
content-visibility
<https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility> (see
also this blog post <https://web.dev/content-visibility/>), which allows
the browser to avoid paying rendering cost for off-screen content. If there
is enough of a buffer of extra content to display, I don't think it should
be necessary to synchronously do the DOM recycling and async scroll events
should suffice.

This approach also takes advantage of all the mature and fast scroll
architectures of existing browsers, and is accessible to find-in-page and
other user agent features.

Chris


On Fri, Jan 15, 2021 at 11:59 AM Felix Lüpke <felix.luepke@cideon.com>
wrote:

> Our company is developing an Angular 10 application which contains a view
> component where up to 500 elements need to be displayed in a scrollable
> list. Each element, while only showing a few short text labels, a thumbnail
> and 4 navigation buttons, is backed by a big Data Object which is loaded
> from different sources and then assembled on view init. We need this data
> to be available when the view is loaded. Rendering all items in a standard
> Angular *ngFor is way too much and will result in the Browser freezing as
> item numbers grow. After testing several approaches we found that using
> VirtualScroll works best for this scenario (pagination isn’t an option for
> us). Existing VirtualScroll implementations didn’t work well so we
> implemented our own. The principle is as follows:
>
> -        An “outer” div with the height a fully rendered list with all
> items would have is used as a base
>
> -        On top of that resides an “inner” div with the height of the
> visible area
>
> -        On there sits an *ngFor which only displays as many items as can
> fit on the div occupying the visible space
>
> -        Scrolling makes the “inner” div move on the “outer” one using
> offsetY, which is calculated using the scroll position, so that is stays in
> the visible area
>
> -        While scrolling, the rendered list items change according to the
> current startIndex which is again calculated from the scroll position
>
>
>
> This creates a scrollable list which feels just like a normal one with the
> advantage that only those items currently visible are painted. This leads
> to the view loading without any freezes. However, as expected (according to
> https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Scroll-linked_effects),
> the performance of this implementation began to drop with nearly every
> FF-update from last Summer onward. It now reached the point where the view
> easily gets jumpy and using a navigation button on an item might lead to a
> wrong route being called, as the visible list item data is (suspected to
> have) run out of sync with the according data model when scrolling.
>
> To be able to implement a flawless VirtualScroll experience we need to be
> able to somehow rely on scroll event data that is in sync with the visible
> part of the scrolling process. As far as I’ve read, the Web Animations as
> well as the CompositorWorker approach could potentially help us with that.
> Is there any information on when any of this will be available in FF?
>
>
>
> Best regards
>
> Felix
>