903460 - AsyncCompositionManager applies async transform and CSS transform in the wrong order

Status: RESOLVED DUPLICATE of bug 732971

(Core :: Graphics: Layers, defect)

Description

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

If you have a point P and you want to transform it by gfx3DMatrix A and then by gfx3DMatrix B, it is equivalent to transform it by gfx3DMatrix C, where C = A * B. That is, matrix transformations are applied in the same order as the multiplication order.

The code in AsyncCompositionManager combines the async transform from the APZC with the CSS transform on the layer, and sets that as the transform on the shadow layer. However, it does the multiplication in the reverse order, so that the async transform is applied first, when in fact we want the async transform to be applied last.

Comment 1

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

I don't think the fix here is just as simple as reversing the matrices; for an APZC-transformed layer at high resolution, the CSS transform will be 1/resolution, and then the APZC transform will be resolution (plus possibly a translation). Currently the effective cumulative transform is:
translation (in layer pixels) * resolution * 1/resolution
but swapping the order would make it this:
1/resolution * translation (in layer pixels) * resolution

so the translation will need to be changed to LayoutDevicePixels instead of LayerPixels to account for this. I'm currently building a patch to verify that what I'm thinking is correct.

Comment 2

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

Attachment: Patch

Based on behaviour I saw on the B2G device, I believe my explanation above was correct. This patch fixes it up.

Comment 3

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

https://tbpl.mozilla.org/?tree=Try&rev=995b9da6a130

Comment 4

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/9813b854b713

Comment 5

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/9813b854b713

Comment 6

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

I must have tested the wrong build on Android or something, because this breaks panning behaviour on Android. It's not obvious to me why yet so I backed out the patch from central.

https://hg.mozilla.org/mozilla-central/rev/9ab28833eda0

Unfortunately today's nightly is pretty bad.

Comment 7

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

Oh, I think this is because of how on Fennec the resolution is applied on the root layer whereas the scrolling is done on the primary scrollable layer. If the resolution were on the primary scrollable layer it would work, but that needs bug 732971 to be fixed first. Sigh.

Comment 8

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

I moved this patch over to bug 732971 as they go hand in hand and must be fixed together in order to not regress Fennec behaviour.