Bug 1429467 - Take ancestors' scales in to account when choosing scale for animations. r?mattwoodrow
Currently ChooseScaleAndSetTransform calls
ComputeDesiredDisplaySizeForAnimation to ensure that the scale chosen
for an individual transform's animation does not result in a layer too
large. However, it does not take in to account the scale chosen for
ancestors. This means that when lots of containers with reasonable
scales are nested we end up with too large a value. This change takes
the incoming scale in to account, meaning the resulting layer size is
capped appropriately.
MozReview-Commit-ID: MTzlMnOARQ
--- a/layout/painting/FrameLayerBuilder.cpp
+++ b/layout/painting/FrameLayerBuilder.cpp
@@ -5449,20 +5449,21 @@ ChooseScaleAndSetTransform(FrameLayerBui
!aContainerFrame->HasPerspective()) {
// If the container's transform is animated off main thread, fix a suitable scale size
// for animation
if (aContainerItem &&
aContainerItem->GetType() == DisplayItemType::TYPE_TRANSFORM &&
EffectCompositor::HasAnimationsForCompositor(
aContainerFrame, eCSSProperty_transform)) {
nsSize displaySize = ComputeDesiredDisplaySizeForAnimation(aContainerFrame);
- // compute scale using the animation on the container (ignoring
- // its ancestors)
+ // compute scale using the animation on the container, taking ancestors in to account
+ nsSize scaledVisibleSize = nsSize(aVisibleRect.Width() * aIncomingScale.mXScale,
+ aVisibleRect.Height() * aIncomingScale.mYScale);
scale = nsLayoutUtils::ComputeSuitableScaleForAnimation(
- aContainerFrame, aVisibleRect.Size(),
+ aContainerFrame, scaledVisibleSize,
displaySize);
// multiply by the scale inherited from ancestors--we use a uniform
// scale factor to prevent blurring when the layer is rotated.
float incomingScale = std::max(aIncomingScale.mXScale, aIncomingScale.mYScale);
scale.width *= incomingScale;
scale.height *= incomingScale;
} else {
// Scale factors are normalized to a power of 2 to reduce the number of resolution changes