Gaia homescreen has 2 scale animations when you open an app, or click the home button when the app is opened and you want to go back to the homescreen. The first one is a zoom-in animation of the homescreen while the app is opened. It goes fast since the animation starts on a source size with has the size of the screen and then the compositor can do his work. The homescreen is scaled 5x. The second one is a zoom-out animation where the homescreen goes back to its normal size. Since the size of the homescreen is 5x bigger than the screen it can't be pre-render by the compositor and then we fail to animate it smoothly. We should starts to pre-render at the target resolution to zoom-out in the compositor first before zooming-in if we want a smooth animation. Milan do you have anyone resource to help with that ?

roc do you agree with the above? We probably want to do this for animations only that start out larger than the screen and scale downwards (we limit painting to screen size and then change the scale).

Jeff has some thoughts on this...

It is worth noting that the different browsers have different behaviour here. If you look at this test case in Safari, FF and Chrome you'll see them: http://people.mozilla.org/~jmuizelaar/implementation-tests/transform.html Safari has the simplest behaviour, best performance and most predictable semantics as an author. It simply always interprets 3d transforms as bitmap transforms. This means they are always fast and you don't ever have to worry about rasterizing at different scales and you don't have any stutter from rerasterizing.

I agree with Jeff. That seems like the best tradeoff.

I would be game to rasterize at higher resolution if no animation is set but for animating content I think Safari has it right.

It also sounds like this is something we would just do, rather than let the user explicitly control the behavior with an attribute.

I'd like to do this for 1.4, but I don't know what size it is. Jeff, how large and complicated is this?

(In reply to Milan Sreckovic [:milan] from comment #7) > I'd like to do this for 1.4, but I don't know what size it is. Jeff, how > large and complicated is this? That's a question much better answered by roc.

It's relatively easy to change our heuristics for setting the resolution. See ChooseScaleAndSetTransform in FrameLayerBuilder.cpp. In particular where we call nsLayoutUtils::GetMaximumAnimatedScale. The downside of the approach in comment #3 is that slow zooming-out animations can look arbitrarily bad and it's difficult for authors to avoid the problem. I think we could change our heuristics in ChooseScaleAndSetTransform so that whenever the chosen resolution makes the layer too big to prerender, reduce it so that we can.

This is feature work. It is too late for 2.0. Move it to backlog and target it to 2.2

Use feature-b2g:2.2? rather than just 2.2.

Let's restart this conversation - Vivien, is this still a problem, and if so, are we doing CSS animation or doing it on the JS side?