773471 - Investigate slow front-end performance of Metro Firefox

Status: RESOLVED FIXED

(Firefox for Metro Graveyard :: General, defect)

Description

[Jonathan Wilde [:jwilde]]

There are a couple of lagginess issues I've observed, but don't have concrete data on yet to assist people with:

- CSS transitions are laggy
- CSS transitions for appbar were smoother when backed with CSS transforms (which aren't hw accelerated)
- Entire UI locks on page load (possibly related to browser/metro/base/content.js)

Comment 1

[Jonathan Wilde [:jwilde]]

# CSS Animation/Transition/Transform Investigations

On the Samsung Series 7 with a release build of mozilla-central running under desktop mode (downloaded from http://nightly.mozilla.org/), the basic CSS animation demo (https://developer.mozilla.org/samples/cssref/animations/cssanim1.html) from MDN is not *terribly* laggy.

Investigating reports on StackOverflow of jQuery animation apparently being smoother than CSS transitions in some cases, I put together a side-by-side comparison of jQuery animation and CSS transitions.

The CSS transitions, as expected, had a higher frame rate than jQuery.  The jQuery animation, however, appeared to have a more constant frame rate.

I'm guessing that the mentions of jQuery being smoother were a visual perception issue.  The CSS transition's frame rate repeatedly increased and decreased over the course of a particular animation sequence, making it look choppier than the jQuery animation, which had a more consistent (albeit slower) frame rate.

As one would expect, JS animations aren't going to speed things up here.

# CSS Transform Performance

The appbar CSS transitions were smoother when moved with transforms than with margins.  By "smoother", I mean that there was some ghosting that happened when using negative margins to move the appbar in and out.

I'll come up with a reduced testcase for this and submit as a bug.

# UI Locking

I'm working on benchmarking and try to track down what bits of JS are likely locking the UI.

In terms of some initial stuff that I've found so far:

MemoryObserver.observe <http://hg.mozilla.org/projects/elm/file/8e164efe3de9/browser/metro/base/content/browser.js#l2392> is used to force GC from JavaScript when the device is very low on memory.  The observe function, when run on the Samsung Series 7, locks the UI for ~2.5 seconds.

Under debug mode, when you press Control-F, it'll run that function <http://hg.mozilla.org/projects/elm/file/8e164efe3de9/browser/metro/base/content/browser.js#l71>, locking the UI for ~2.5 seconds and then eventually showing the find-in-page widget.

At the very least, we should switch that debug key over over to a different shortcut.  But, do we even need MemoryObserver at all?

Comment 2

[Jim Mathies [:jimm]]

awesome research.

On MemoryObserver.observe, I don't think so, this was oriented around cell phones with limited memory. Which reminds me, we might want to take a look at default prefs - 

http://mxr.mozilla.org/projects-central/source/elm/browser/metro/profile/metro.js

There are a number of setting in there related to gc, memory use, performance, etc. that could stand to be reset to prefs similar to what we use in desktop fx.

Comment 3

[Jonathan Wilde [:jwilde]]

Attachment: Comparing jQuery animate and CSS transitions

Here's the specific test case that I mentioned earlier for comparing jQuery animate and CSS transitions.

On a modern desktop, CSS transitions look better, hands down.  That comparison becomes fuzzier on slower hardware.

Comment 4

[Jonathan Wilde [:jwilde]]

(In reply to Jim Mathies [:jimm] from comment #2)
> On MemoryObserver.observe, I don't think so, this was oriented around cell
> phones with limited memory. 

Will remove this, then.

> Which reminds me, we might want to take a look at default prefs - 
> 
> http://mxr.mozilla.org/projects-central/source/elm/browser/metro/profile/
> metro.js
> 
> There are a number of setting in there related to gc, memory use,
> performance, etc. that could stand to be reset to prefs similar to what we
> use in desktop fx.

Filing a bug to investigate the performance impact of that.  Aligning these with desktop FX would ultimately be a good thing, anyway--less stuff for future devs to trip over.

Comment 5

[Jim Mathies [:jimm]]

cc'ing a couple gfx folks who might have some thoughts on CSS transitions vs jQuery performance and Direct2D.

Comment 6

[Jim Mathies [:jimm]]

Forward from an email from Chris Jones on the b2g team, something to investigate - 

--
FYI, we found out a long time ago when hacking around with b2g that the default timer heuristics used by the refresh driver aren't really what one wants for high frame-rate animations.  If the xul-fennec frontend code uses requestAnimationFrame(), which as I recall it did, you can expect a fps boost by just flipping a pref

http://mxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js#392

We saw about a 30% fps increase on b2g after flipping that.  Kinda frustrating in hindsight, wrt the old xul-fennec for android.

As the comment notes, I filed a bug on enabling this for all platforms, but there was a talos regression on win32 that I haven't had time to sort out.  (I think it's from us, like, repainting at a higher rate :/.)
--