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. [1] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/client/ClientTiledThebesLayer.cpp?rev=e26cfd8267fa#145

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 y-scales. 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.

I'm going to mark this bug as fixed, since all three stages have landed and stuck.

\o/