Open Bug 1426279 Opened 4 years ago Updated 1 month ago

Try to retain scrolled display items when scrolling


(Core :: Web Painting, enhancement, P3)




Tracking Status
firefox59 --- affected


(Reporter: mattwoodrow, Unassigned)


(Blocks 1 open bug)


Currently, we can't retain any scrolled display items during scrolling since they change in position (stored on the display item) and we need to rebuild them to update them.

This isn't ideal, since scrolling is a very common interaction, and with APZ, there tends to be a lot of scrolled items.

There are two possible approaches I can think of:

* Change scrolled display items to have a constant position when scrolled, and add a wrapper item around the set that translates to the current scroll offset.

We'd need to make the scrolled frame a reference frame (like we do for transforms) so that all scrolled display items get positions relative to that.

Scroll frames can have descendants that don't scroll (position:fixed!), so these would need to be outside of the wrapper item. This can get really complicated (when there is interleaved scrolled/unscrolled content), plus the two different types of clips, so it might be better to only do this when all content is scrolled.

* Add a way to update the required fields on scrolled display items. As part of the merging process we could detect items that have been scrolled and update the position on them. Items might have used the existing position as part of various cached calculations though, so a very careful audit of all the places that need to be updated would need to be done.

We'd also need: 

To teach merging about how to remove items that are still valid, but have been scrolled out of view and to remove them.

To build a partial display list for the area that just got scrolled into view.

We currently store visible rects on the display items that is usually just a copy of the display list building area (until the FLB ComputeVisibility pass reduces it to something unique). We could probably move this off of the item, and into some shared location (maybe the ASR, since those are usually what introduces a new displayport/building area) and then we won't need to update it in as many places.
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.