Closed Bug 993525 (apz-css-transforms) Opened 6 years ago Closed 5 years ago

[meta] Make APZ play nicely with CSS transforms


(Core :: Panning and Zooming, defect)

Gonk (Firefox OS)
Not set





(Reporter: kats, Assigned: botond)



(Keywords: meta)

Although we have consider CSS transforms interacting with APZ in some areas of the code, it seems to be mostly ad-hoc and not well defined. I think we need to spend some time thinking about an overall design for how this should work, and make sure everybody understands it.
When working on this bug, please note the comment in ClientTiledThebesLayer::BeginPaint() [1] that says:

    // Note that below we use GetZoomToParent() in a number of places. Because this
    // code runs on the client side, the mTransformScale field of the FrameMetrics
    // will not have been set. This can result in incorrect values being returned
    // by GetZoomToParent() when we have CSS transforms set on some of these layers.
    // This code should be audited and updated as part of fixing bug 993525.

No longer blocks: 1035598
No longer blocks: 989403
Alias: apz-css-transforms
Assignee: nobody → botond
No longer blocks: 1027633
Depends on: 1066259
After a lot of thinking, trying things out, and discussions, I've identified three deficiencies in the handling of CSS transforms (and particularly, of the resolutions they induce) by APZ and Layout:

  1) The resolution induced by a CSS scale transform on a scrollable layer or any 
     ancestor layer thereof (henceforth, "css-driven resolution") is not taken into 
     account by anything in the FrameMetrics of that scrollable layer. In particular, 
     I believe it should be included in FrameMetrics::mCumulativeResolution.

  2) In cases where Layout chooses to paint a scrollable layer at a resolution 
     different from the scale of a CSS transform on that layer, the additional scale 
     (i.e. the portion of the transform:scale which is not already reflected in the 
     resolution) is  not taken into account by anything in the FrameMetrics of that
     scrollable layer.

     Taking this into account wouldn't be very straightforward, because the relevant
     information is not readily accessible in ComputeFrameMetrics(). However, I've 
     identified that this scenario only happens when we build a container layer for
     the scroll frame; it doesn't happen with containerless scrolling.

     Since multi-layer-apz (bug 967844), we've been during containerless scrolling
     for scroll frames that are not root scroll frames. Since we're planning to 
     switch to containerless scrolling for root scroll frames as well, I'm going to
     treat that as the fix for this issue.

  3) APZ code assumes that the resolution at which a layer is painted has the same
     x- and y- components, and accordingly the various scales it maintains that can
     include a resolution (for example, FrameMetrics::mCumulativeResolution) are just
     a single number. We need to modify these scales to accomodate different x- and

I'm going to fix this bug in three stages, each fixing one of the above problems. Stage 2 will require some Layout-side changes, for which I'll need Timothy's help.
Blocks: 1052474
No longer depends on: 1052474
No longer blocks: 1055741
Depends on: apz-css-trans-stage1
No longer depends on: 1066259
I'm going to mark this bug as fixed, since all three stages have landed and stuck.
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.