Closed
Bug 963928
Opened 11 years ago
Closed 8 months ago
Starts zooming-in at target resolution for animations
Categories
(Core :: Graphics: Layers, defect)
Core
Graphics: Layers
Tracking
()
People
(Reporter: vingtetun, Unassigned)
References
Details
(Whiteboard: [2.1-flame-test-run-1])
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 ?
Flags: needinfo?(milan)
Comment 1•11 years ago
|
||
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•11 years ago
|
||
Jeff has some thoughts on this...
Flags: needinfo?(milan) → needinfo?(jmuizelaar)
Comment 3•11 years ago
|
||
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.
Flags: needinfo?(jmuizelaar)
Comment 4•11 years ago
|
||
I agree with Jeff. That seems like the best tradeoff.
Comment 5•11 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
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?
blocking-b2g: --- → 1.4?
Flags: needinfo?(jmuizelaar)
Comment 8•11 years ago
|
||
(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.
Flags: needinfo?(jmuizelaar) → needinfo?(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.
Flags: needinfo?(roc)
Updated•11 years ago
|
blocking-b2g: 1.4? → 1.5?
Comment 10•11 years ago
|
||
This is feature work. It is too late for 2.0. Move it to backlog and target it to 2.2
blocking-b2g: 2.0? → backlog
feature-b2g: --- → 2.2
Updated•11 years ago
|
Blocks: Graphics_Backlog
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.1:
--- → affected
Flags: needinfo?(ktucker)
Whiteboard: [2.1-flame-test-run-1]
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Comment 12•10 years ago
|
||
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?
Flags: needinfo?(21)
Updated•10 years ago
|
feature-b2g: 2.2? → ---
Assignee | ||
Updated•10 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
Updated•10 years ago
|
Flags: needinfo?(milan)
Updated•9 years ago
|
Flags: needinfo?(milan)
Updated•2 years ago
|
Severity: normal → S3
Comment 13•8 months ago
|
||
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.
Flags: needinfo?(21)
Comment 14•8 months ago
|
||
Closing old B2G bugs
Status: NEW → RESOLVED
Closed: 8 months ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•