884148 - Incrementally update display lists

Status: RESOLVED DUPLICATE of bug 1352499

(Core :: Layout, defect)

Description

[Matt Woodrow (:mattwoodrow)]

I think the easiest way to do this would be to pass flags to nsIFrame::SchedulePaint that describe the type of change that is being made.

We can use this to build a list of frame:change pairs to apply to the previous display list. If the list ever gets too complicated, or we get an unknown type (the default), then we can dump everything and fallback to building a new display list.

The simplest case is when a frame just changes its mRect. I think the only change we'd need to make to the display list is walk the item (and all descendants) and update their cached value of ToReferenceFrame().

When scrolling, we usually only get two callers to SchedulePaint, one from nsGfxScrollFrame::ScrollVisual, and one from moving the scrollbar thumb position. Both of these should fall into the above category.

So I think by implementing a single hint and changing two SchedulePaint callers, we could significantly reduce the display list building overhead when scrolling.

We could then add other hints and callers as we see a need.

Comment 1

[Matt Woodrow (:mattwoodrow)]

We also discussed changing active scroll roots to be display list reference frames. This would mean that scrolling doesn't change the ToReferenceFrame() value of the scrolled items, and we could avoid having to update them.

I think this change is going to be fairly difficult, especially during layer building. We'd need to make sure that all the scrolled content goes in a separate layer from fixed content (which it should be), and apply a transform to the layer. Handling BasicLayers' flatten component alpha mode would be especially bug prone.

I think we should get significant win from implementing what I suggested in Comment 0, and we can always add this later if the cost of updating the cached ToReferenceFrame values ends up being significant.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

If this does what it sounds like it should do, it would probably take care of the regressions we're seeing in tp5o_scroll (bug 1179735) and generally help with the talos fallout from APZ's larger displayport.

Comment 3

[Mayank Bansal]

dupe of bug 1352499 ?

Comment 4

[Miko Mynttinen]

(In reply to Mayank Bansal from comment #3)

dupe of bug 1352499 ?

Yes.