This apparently regressed by recent task switcher changes. Please file these bugs! I know it's hard to believe, but there are bugs in the platform, and platform folks can't read minds. STR (1) Open dialer (2) Long-press HOME The dialer content jumps around during the opening animation. If you repeat the same steps with the browser (in-process), you can see it quite obviously being repainted at different resolutions during the animation, but apparently not being reflowed. Both of these things are ~bugs, but obviously the rendering artifacts are worse. There's one definite apparent bug: trying to resolution-scale nsDisplayRemote, which is incapable of synchronously repainting. We should never try to do that. I think this should be a relatively simple fix. However, there may be two ancillary issues contributing to the glitch A. Animation not being made async. The amount of resolution repainting is surprisingly high during the animation. If so, making it async may alleviate. B. If the animation *is* being made async, then bug 780692 will "fix" this by keeping the main thread idle during the animation.

(In reply to Chris Jones [:cjones] [:warhammer] from comment #0) > This apparently regressed by recent task switcher changes. Please file > these bugs! I know it's hard to believe, but there are bugs in the > platform, and platform folks can't read minds. Sorry about that, I thought this was a result of bug 792351.

OK cool, this fixes it diff --git a/layout/base/FrameLayerBuilder.cpp b/layout/base/FrameLayerBuilder.cpp --- a/layout/base/FrameLayerBuilder.cpp +++ b/layout/base/FrameLayerBuilder.cpp @@ -2590,17 +2590,17 @@ ChooseScaleAndSetTransform(FrameLayerBui gfxMatrix transform2d; bool canDraw2D = transform.CanDraw2D(&transform2d); gfxSize scale; bool isRetained = aLayerBuilder->GetRetainingLayerManager() == aLayer->Manager(); // Only fiddle with scale factors for the retaining layer manager, since // it only matters for retained layers // XXX Should we do something for 3D transforms? - if (canDraw2D && isRetained) { + if (0 && canDraw2D && isRetained) { //Scale factors are normalized to a power of 2 to reduce the number of resolution changes scale = transform2d.ScaleFactors(true); // For frames with a changing transform that's not just a translation, // round scale factors up to nearest power-of-2 boundary so that we don't // keep having to redraw the content as it scales up and down. Rounding up to nearest // power-of-2 boundary ensures we never scale up, only down --- avoiding // jaggies. It also ensures we never scale down by more than a factor of 2, // avoiding bad downscaling quality. Now to see how I ask if we're transforming a DisplayRemote ...

BuildContainerLayerFor knows.

It does, but we've already chosen the transform and resolution by the time we walk the child list, AFAICT. What did you have in mind?

I'd like to write a test for this bug we don't have the capability.

Comment on attachment 677649 [details] [diff] [review] Make containers for DisplayRemote behave like ThebesLayers when we're resolution-scaling Review of attachment 677649 [details] [diff] [review]: ----------------------------------------------------------------- Looks good. 'behave like a leaf layer' might be a better description. ::: layout/ipc/RenderFrameParent.cpp @@ +669,5 @@ > + gfx3DMatrix::Translation(rootFrameOffset.x, rootFrameOffset.y, 0.0); > + // Remote content can't be repainted by us, so we multiply down > + // the resolution that our container expects onto our container. > + m.Scale(aContainerParameters.mXScale, aContainerParameters.mYScale, 1.0); > + layer->SetBaseTransform(m); I wonder why SetPostScale didn't work. This is the line that applies the scale to all other leaf layers: http://mxr.mozilla.org/mozilla-central/source/layout/base/FrameLayerBuilder.cpp#2073

(In reply to Matt Woodrow (:mattwoodrow) from comment #7) > Comment on attachment 677649 [details] [diff] [review] > Make containers for DisplayRemote behave like ThebesLayers when we're > resolution-scaling > > Review of attachment 677649 [details] [diff] [review]: > ----------------------------------------------------------------- > > Looks good. 'behave like a leaf layer' might be a better description. > Certainly, will change. > ::: layout/ipc/RenderFrameParent.cpp > @@ +669,5 @@ > > + gfx3DMatrix::Translation(rootFrameOffset.x, rootFrameOffset.y, 0.0); > > + // Remote content can't be repainted by us, so we multiply down > > + // the resolution that our container expects onto our container. > > + m.Scale(aContainerParameters.mXScale, aContainerParameters.mYScale, 1.0); > > + layer->SetBaseTransform(m); > > I wonder why SetPostScale didn't work. > > This is the line that applies the scale to all other leaf layers: > > http://mxr.mozilla.org/mozilla-central/source/layout/base/FrameLayerBuilder. > cpp#2073 Oh; the comments in CompositorParent led me to believe that the resolution scale was set in the leaf layer's mTransform. That doesn't make me very happy :(.