941210 - APZCTreeManager builds a wrong APZC tree for some layer trees

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect)

Description

[Botond Ballo [:botond]]

For example, for the following layer tree (note: siblings are printed in backwards order because that's the order in which UpdatePanZoomControllerTree processes them):

I/Gecko   (  139): [apxc] ContainerLayerComposite       (0, 0)
I/Gecko   (  139): [apxc]   ContainerLayerComposite     (0, 0)
I/Gecko   (  139): [apxc]     ContainerLayerComposite   (0, 0)  APZC (1, 5, 2)  [0, 320] x [40, 410]
I/Gecko   (  139): [apxc]     ContainerLayerComposite   (0, 20)
I/Gecko   (  139): [apxc]       RefLayerComposite       (0, 50)
I/Gecko   (  139): [apxc]         ContainerLayerComposite       (0, 0)  APZC (4, 1, 1)  [0, 320] x [0, 365]
I/Gecko   (  139): [apxc]           ThebesLayerComposite        (0, 0)
I/Gecko   (  139): [apxc]       ThebesLayerComposite    (0, 0)
I/Gecko   (  139): [apxc]     ThebesLayerComposite      (0, 0)
I/Gecko   (  139): [apxc]   ColorLayerComposite (0, 0)
I/Gecko   (  139): [apxc]   ThebesLayerComposite        (0, 0)
I/Gecko   (  139): [apxc] [UpdatePanZoomControllerTree end]

The APZC tree that gets built has the (4, 1, 1) APZC at the root, and no siblings or children. The (1, 5, 2) APZC is lost.

Comment 1

[Botond Ballo [:botond]]

Attachment: bug941210.patch

Comment 2

[Botond Ballo [:botond]]

https://hg.mozilla.org/integration/b2g-inbound/rev/54091ba5f2c5

Comment 3

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/54091ba5f2c5