963928 - Starts zooming-in at target resolution for animations

Status: RESOLVED INVALID

(Core :: Graphics: Layers, defect)

Description

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

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 ?

Comment 1

[Andreas Gal :gal]

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).

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

Jeff has some thoughts on this...

Comment 3

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 4

[Andreas Gal :gal]

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

Comment 5

[Andreas Gal :gal]

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

Comment 6

[Milan Sreckovic [:milan] (needinfo for best results)]

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

Comment 7

[Milan Sreckovic [:milan] (needinfo for best results)]

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?

Comment 8

[Jeff Muizelaar [:jrmuizel]]

(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.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 10

[Ivan Tsay (:ITsay)]

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

Comment 11

[Kai-Chih Hu [:khu]]

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

Comment 12

[Milan Sreckovic [:milan] (needinfo for best results)]

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?

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Comment 14

[Gregory Pappas [:gregp]]

Closing old B2G bugs