860162 - AsyncPanZoomController doesn't apply proper scroll compensation if the root layer has a scale

Status: RESOLVED DUPLICATE of bug 866265

(Core :: Graphics: Layers, defect)

Description

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

Attachment: Fix scrollCompensation

The scrollCompensation calculation in AsyncPanZoomController appears to be wrong, causing much jank-like behaviour and general wonkiness on Fennec. I have a patch that fixes this but I don't know if it helps or hurts B2G. I'll need to get a B2G build set up so I can test it. Putting the patch up here in case people want to stare at it for a while, because it takes a while to understand what's going on.

Comment 1

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

Comment on attachment 735595 [details] [diff] [review]
Fix scrollCompensation

Getting a B2G build up and running is proving to be more impossible than I expected it to. I'll keep at it but in the meantime if you have some spare cycles and can test out this patch to ensure that B2G isn't adversely affected that would be great.

Comment 2

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

The patch isn't working properly on b2g. It scrolls faster than your finger when zoomed out and slower than your finger when zoomed in.

Comment 3

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

Ok, I finally got B2G up and running in the emulator-x86 configuration and can reproduce the problem. I should be able to debug it and figure out what's going on.

Comment 4

[Milan Sreckovic [:milan] (needinfo for best results)]

Naive questions, based on the patch: what's special about the root transformation?  I can see either not caring, or caring about the cumulative transformation above the node.  As I said, naive question.

Comment 5

[Benoit Girard (:BenWa)]

I think we're cleaning up code while still preserving the assumptions that only the direct child of the root can be a APZC for now.

We should watch out when computing the cumulative transform because if we're rendering to an intermediate surface then the cumulative transform stops there, at least the one used to position the layers. We'll need to be careful how to handle that with APZC otherwise we might see some nasty glitches as layout toggles the use of intermediate surfaces.

Comment 6

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

(In reply to Milan Sreckovic [:milan] from comment #4)
> Naive questions, based on the patch: what's special about the root
> transformation?  I can see either not caring, or caring about the cumulative
> transformation above the node.  As I said, naive question.

In Fennec (and I thought in B2G as well) the scale transformation is applied on the root layer. This is "for historical reasons" (i.e. because bug 732971 was not, and still isn't, fixed). Reading the scale from the layer bound to the APZC, in Fennec, gives 1.0. It's not a cumulative transformation. I hope that answers your question, but I may have misunderstood.

Comment 7

[Milan Sreckovic [:milan] (needinfo for best results)]

Cool, just checking.  Perhaps worth an assert or two in case these assumptions change...

Comment 8

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

The correct fix here involves fixing bug 732971 first, I think.

Comment 9

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

This is fixed by part 4 on bug 866265.