Containerless scrolling means that the pan zoom controller applies it's transforms (to compensate for differences between the state of layout the last time we painted and the current state as composited to the screen) to the layers that are scrolled instead of the container layer that contains the layers that scroll.
When running test_animations_omta.html there is a zoom of 1.306122 applied, and the page is scrolled down to 67 screen pixels (before the test starts, not sure why exactly). Gecko scrolls as close to 67 screen pixels as it can: 67/1.306122 = 51.29689 css pixels, which is 3077.813 appunits. Gecko scrolls to 3078 app units. When AsyncCompositionManager::TransformScrollableLayer runs we calculate the scroll position of gecko and the current scroll position that the pan zoom controller is using. Since there are no async pan or zoom operations taking place these should match. However when the gecko scroll position is calculated we get 3078/60*1.306122 = 67.0040586. So it applies a transform of 0.0040586 to the container layer for the transform that test_animations_omta.html is animating off main thread. When test_animations_omta.html reads the transform of this layer it fails because it's expecting 0 and 0.0040586 is outside of it's epsilon for considering it to be close enough.
Containerless scrolling means that the pan zoom controller applies it's transforms (to compensate for differences between the state of layout the last time we painted and the current state as composited to the screen) to the layers that are scrolled instead of the container layer that contains the layers that scroll.
When running test_animations_omta.html there is a zoom of 1.306122 applied, and the page is scrolled down to 67 screen pixels (before the test starts, not sure why exactly). Gecko scrolls as close to 67 screen pixels as it can: 67/1.306122 = 51.29689 css pixels, which is 3077.813 appunits. Gecko scrolls to 3078 app units. When AsyncCompositionManager::TransformScrollableLayer runs we calculate the scroll position of gecko and the current scroll position that the pan zoom controller is using. Since there are no async pan or zoom operations taking place these should match. However when the gecko scroll position is calculated we get 3078/60*1.306122 = 67.0040586. So it applies a transform of 0.0040586 to the container layer for the transform that test_animations_omta.html is animating off main thread. When test_animations_omta.html reads the transform of this layer it fails because it's expecting 0 and 0.0040586 is outside of it's epsilon for considering it to be close enough.
This avoids accumulating floating point error from conversion, so that
when we switch to doubles at the start of
nsCSSValue::GetAngleValueInRadians we're using the original unit, rather
than a different one that will round differently.
Bug 1113425 (specifically, part 2:
https://hg.mozilla.org/mozilla-central/rev/bb3866dea03e) introduced a fix for
a race condition that occurs when querying the animated transform of a layer.
However, that fix failed to update CrossProcessCompositorParent and hence the
issue still arises when e10s is enabled.
This patch applies the fix from that bug to CrossProcessCompositorParent.
When remote browsing, swap the MozLayersReady callback in the compositor
when dragging tabs between windows.
--HG--
extra : rebase_source : 717b8317bc3afbab7daa8856573d48b2ed5ca2cc
Change interface of getter/setter for mClipRect,
also necessary modification for codes that use these resources.
* * *
Bundle mUseClipRect and mClipRect as Maybe<ParentLayerIntRect> mClipRect
--HG--
extra : rebase_source : ca0c60404a28b7418df88104b863760033289910
There is a data racing problem in IsValidKey() and we don't need to check the
index in serializer. The index is always invalid when we alloc new buffer.
