864147 - Improve prerendering requirements/heuristics for OMTA

Status: NEW

(Core :: Layout, defect)

Description

[henryfhchan]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:23.0) Gecko/20130416 Firefox/23.0
Build ID: 20130416030901

Steps to reproduce:

1. Visit http://jsecs.org/
2. Tap the logo
3. Watch the side menu transit in (via transform:translateX(-272px) and transition:transform .3s)


Actual results:

Firefox for Android's translate+transition is very jerky (3-4 frames).
Compared with Dolphin Browser (buttery-smooth.  soap-opera feel).

This is on a Samsung Galaxy W (GT-I8150) which has only 512 MB RAM according to specs (351 MB RAM in task manager). Android OS 2.3.6 Gingerbread.  Pushed to market around Aug 2011.  Factory default non-rooted.  Clean install (2013-04-20) new profile (data cleared via settings).

Comment 1

[Aaron Train [:aaronmt]]

Performance on a high-end device such as my Galaxy Note II is rather fine, I suspect this is at the mercy of the device at hand. Open question, are there existing core Gecko bugs for improving  transform/transition performance on all platforms?

Comment 2

[Chris Lord [:cwiiis]]

I think this will largely depend on bug 788522 (which is why, for the most part, perf is good on low-end b2g devices).

Comment 3

[henryfhchan]

Additional Information: Stock is buttery smooth too. Does stock browser use off-main-thread stuff on Gingerbread?

Comment 4

[Chris Lord [:cwiiis]]

(In reply to henryfhchan from comment #3)
> Additional Information: Stock is buttery smooth too. Does stock browser use
> off-main-thread stuff on Gingerbread?

Stock on Gingerbread has synchronous rendering, afaik, which for animations could be better than async without async animations (you may not have the extra copy/composite steps, and you don't have the comms overhead).

That said, in an ideal case the difference in performance between sync and async animations ought to just be the cost of display-list building. If there are any particularly poor test-cases, please report/attach them - they may be indicative of other bugs that we'll need to fix regardless.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

Firefox for Android has had async transform animations for some time now, so I would expect this issue to no longer happen. Are you still able to reproduce on a recent Firefox (assuming you still have the device)?

Comment 6

[henryfhchan]

The website menu is gone already. But navigation between pages (also transform translate + opacity) feels extremely laggy even on my new flagship LG G3.

Comment 7

[henryfhchan]

The interactive carousel on  http://jsecs.org/about-us/33rd-jsecs is animates smooth as butter on chrome for android on my LG G3 after a few trials (probably after their heuristics kick in.)  It too is powered by simple translate and opacity.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Thanks for the update!

(In reply to henryfhchan from comment #7)
> The interactive carousel on  http://jsecs.org/about-us/33rd-jsecs

I assume you're referring to the carousel of committee members near the top of the page. This seems pretty smooth in Firefox for Android as well, when I click on an individual committee member's photo.

(In reply to henryfhchan from comment #6)
> The website menu is gone already. But navigation between pages (also
> transform translate + opacity) feels extremely laggy even on my new flagship
> LG G3.

Navigating "between pages" (i.e. when I click on "Year Theme" or go back to "The Committee" is laggy, yes. When I do this I see the following in logcat:

I/Gecko   ( 4996): Performance warning: Async animation disabled because frame size (384, 2453) is bigger than the viewport (432, 584) or the visual rectangle (384, 2453) is larger than the max allowable value (17895698) [div with id 'pg1000']

which indicates that the async-transformed div is too large for us to async transform it. Not entirely surprising since it's pretty much the entire page (2453 pixels tall). It would take up too much memory to render the entire thing; I don't think we have any plans to change this. If this is the only issue remaining I think it's a WONTFIX or WORKSFORME.

Comment 9

[henryfhchan]

> I assume you're referring to the carousel of committee members near the top of the page. This seems pretty smooth in Firefox for Android as well, when I click on an individual committee member's photo.

About the carousel of the committee members, it only renders the first or last few frames of the animation.  The first value of the frame counter hovers between 010 - 025.  The page also re-renders in low-resolution mode and re-renders in high-resolution mode when done.

> which indicates that the async-transformed div is too large for us to async transform it. Not entirely surprising since it's pretty much the entire page (2453 pixels tall). It would take up too much memory to render the entire thing; I don't think we have any plans to change this. If this is the only issue remaining I think it's a WONTFIX or WORKSFORME.

I see your point.  This might deserve to be in its own bug, but I also tested on my laptop, and the page transform animation is laggy as well, yet chrome and IE do so butter smooth, even when touch flinging.  Would it be possible to clamp the frame size down to viewport + buffer, then async transform that, and checkboard + fallback to non-async only when scrolling?

Comment 10

[henryfhchan]

> About the carousel of the committee members, it only renders the first or last few frames of the animation.  The first value of the frame counter hovers between 010 - 025.  The page also re-renders in low-resolution mode and re-renders in high-resolution mode when done.

Adding `will-change:transform` on #pg1000_slide (the carousel) makes the animation noticeably smoother despite the counter never exceeding 020.  But then the whole page renders in low-resolution mode at all times.

I suspect that forcing the #pg1000_slide into separate layer causes Firefox to hit some kind of RAM limit.  Chrome is completely fine with it, no lags, no low-resolution, no checkerboarding.

To add, the LG G3 has a resolution of 3 dppx, so 1 pixel becomes 9.

Comment 11

[henryfhchan]

(not to say, the scrolling performance sucks as well on LG G3.)

Comment 12

[Kartikaya Gupta (email:[e-mail])]

(In reply to henryfhchan from comment #9)
> About the carousel of the committee members, it only renders the first or
> last few frames of the animation.

Interesting, I don't see this on a Nexus 4. The animation seems to be as good as in Chrome as far as I can tell.

> The first value of the frame counter
> hovers between 010 - 025.

For me it goes up to around 35. But yeah that's probably something that could be improved.

> The page also re-renders in low-resolution mode
> and re-renders in high-resolution mode when done.

What I'm seeing is that the text is a little blurry, but that's because the layer is being scaled vertically (same issue as in bug 1144534). It's not the same low-resolution mode as you would see while panning fast and going into checkerboarding. Can you tell if you're seeing the same thing? A screenshot of the low-res might help. If you're seeing the former, then we can track that as part of bug 1144534, and I would expect bug 1097464 to partially or completely fix that. If you're seeing the latter, then that's a more serious issue and I'd like to open a separate bug for that.

> I see your point.  This might deserve to be in its own bug, but I also
> tested on my laptop, and the page transform animation is laggy as well, yet
> chrome and IE do so butter smooth, even when touch flinging.

On my Mac laptop, Chrome does seem to do a bit better than Firefox but it's pretty close and hard for me to tell.

> Would it be
> possible to clamp the frame size down to viewport + buffer, then async
> transform that, and checkboard + fallback to non-async only when scrolling?

That's something that might work on this page, although I don't know if it would hold up well across the web in general. There are definitely cases where the CSS transform moves contents that are out of view into view and if we haven't rendered that offscreen portion we're definitely going to checkerboard, regardless of scrolling. Matt/Brian, any thoughts on this?

Comment 13

[Matt Woodrow (:mattwoodrow)]

We could be smarter about our prerendering requirements for sure.

Currently we require the entire frame to be prerendered (and within the size requirements for that) before we'll let the transform by run asynchronously.

We could instead inspect the transform animation, determine which areas can potentially become visible because of it (only content in the x direction for this example) and then see if that size is acceptable. We could do this for simple translation only transforms, it gets hard very quickly to try solve it for all cases.

Comment 14

[Brian Birtles (:birtles)]

(In reply to Matt Woodrow (:mattwoodrow) from comment #13)
> We could instead inspect the transform animation, determine which areas can
> potentially become visible because of it (only content in the x direction
> for this example) and then see if that size is acceptable. We could do this
> for simple translation only transforms, it gets hard very quickly to try
> solve it for all cases.

Sounds reasonable to me. I guess it would be similar to the way we dig into animations to work out the min/max animated scale in nsLayoutUtils.

Comment 15

[Kartikaya Gupta (email:[e-mail])]

Thanks, I'm going to repurpose this bug for that and move it to Layout.