1417888 - The 57 first run page can't run smoothly without GPU compositing.

Status: RESOLVED FIXED

(www.mozilla.org :: Pages & Content, defect)

Description

[Nicolas Silva [:nical]]

The 57 first run page: https://www.mozilla.org/en-US/firefox/57.0/firstrun/
uses a lot of transparent animated shapes. It's a beautiful, but very demanding animation and while GPU compositor backends can run it well, the basic compositor just backend can't do that much blending at interactive frame rates.

I have a rather beefy i7 laptop which runs this page at about 3 fps.

The basic compositor backend is used by about a 1/5th of our user base (all linux users and a good chunk of the windows population).

Comment 1

[Alex Gibson [:agibson]]

Thanks for the detailed description is the issue. Two more questions that would be very helpful before I ping others on this:

1.) Does the performance negatively impact / impair people's ability to sign in/up to a Firefox Account?
2.) Is there a pref we can flip to test this?

Thanks

Comment 2

[Nicolas Silva [:nical]]

It the page isn't very responsive but (patient) users should be able to sign up or sign in.

To test this, I think that flipping the pref "layers.acceleration.disabled" to true should do (preferably testing on consumer hardware rather than our powerful work laptops, but right now even the powerful ones appear to be having a hard time). Or use the default configuration on linux.

Comment 3

[Alex Gibson [:agibson]]

Peter, Eric: we may have quite a bad performance issue here that could impact /firstrun sign-ups. It also doesn't paint a great first impression given our current marketing campaign that focuses on speed, given that this is the first web page users see with a new profile.

Peter - can you take a look in GA at how this might be effecting Linux & Windows users in terms of conversions?

Comment 4

[pgerman]

Data shared over slack with websites team. 

Key take away - Conversion is up for 57 vs 56 over the last couple days, however this is still a bad experience and should be remedied.

Comment 5

[Erica Wright [:ewright]]

I tested this in a VM, it was also using a basic compositor. The wave portion performed well around 50fps, the spin portion fell sharply, but still looked acceptable. This was also tested on multiple windows machines and on the reference hardware and performed well.

Comment 6

[Alex Gibson [:agibson]]

When I test the page using "layers.acceleration.disabled" set to "true" the new animation moves at around 10fps for me (on a 2017 MBP). It also noticably slows down text entry into the accounts form, making the page feel sluggish.

We're going to formulate what the next steps are here.

Comment 7

[Erica Wright [:ewright]]

Perhaps we disable the animation on Linux? Specifically for Windows, is there a way to tell which machines the performance is poor on before we run and show them a still version instead?

Comment 8

[Alex Gibson [:agibson]]

(In reply to Erica Wright [:ewright] from comment #7)
> Perhaps we disable the animation on Linux? Specifically for Windows, is
> there a way to tell which machines the performance is poor on before we run
> and show them a still version instead?

We could diable it for Linux users, but we can't detect GPU compositing on the client for the remaining Windows users. We may need to come up with an alternate strategy.

Comment 9

[Blake Winton (:bwinton) (:☕️)]

Looking at https://sql.telemetry.mozilla.org/queries/49205/source it seems that Windows 7 has about 25% basic compositor, whereas Windows 8 and up have about 7.6% basic compositor, so I would suggest also disabling animations for Windows 7 and lower. (And living with the poor perf on that 7.6% while we come up with a better fix…)

Comment 10

[Jeff Muizelaar [:jrmuizel]]

It feels like the safe thing to do is disable it everywhere and only enable it in places where we know it can go fast. (Perhaps only on Mac)

Comment 11

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub pull-request: https://github.com/mozilla/bedrock/pull/5295

Comment 12

[David Teller [:Yoric] - still alive but not very active]

Agreed with jrmuizel. The immediate stop should be to disable it everywhere, then progressively enable it on platforms where we are confident it won't ruin the experience.

Comment 13

[[github robot]]

Commit pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/ce3f45a6fd2f54b7e051c61700fb912b431ec49b
[bug 1417888] Disable firstrun animation for Linux and Win7

Comment 14

[Craig Cook (:craigcook)]

Our quick patch is now live in production. The animation should only run on Macs and on Windows 8 or higher. All others get a static background and a simplified end transition. Can folks on this bug help us verify that the page works as expected, nothing is newly broken, and that performance is improved?

I'm still hopeful that we can revisit the design and come up with something that can be sleek and impressive without being quite so processor-intensive, but that will take more time. This was a quick fix to at least stop grinding those machines to a crawl while we figure out something that will work for all platforms and hardware configurations.

Comment 15

[Alex Gibson [:agibson]]

I also noticed in the console I see the following warning (using macOS):

"Will-change memory consumption is too high. Budget limit is the document surface area multiplied by 3 (748846 px). Occurrences of will-change over the budget will be ignored."

This likely isn't the cause of the performance issue, but probably because we're trying to use `will-change` on a layer that's too big to be safely GPU composited.

Comment 16

[Craig Cook (:craigcook)]

This was resolved on 17 November (see comment 13) but we neglected to mark the bug resolved. Sorry about that.

Comment 17

[Alex Gibson [:agibson]]

Reopening this, as even with the workaround for certain machines that page still performs poorly.

Comment 18

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub pull-request: https://github.com/mozilla/bedrock/pull/5520

Comment 19

[[github robot]]

Commit pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/246c8b271eaa367cd8ba9289747b0313434a9a27
[fix bug 1417888] Remove /firstrun bg animation. (#5520)

- Also fixes bug 1447724 - text artifacts caused by svg animation

Comment 20

[Alex Gibson [:agibson]]

Re-opening this bug, as even now my machine (brand new MBP) still uses ~70-90% CPU when viewing this page. Not only does Firefox feel sluggish, but my whole OS slows down (typing feels less responsive, dock animation has a very low FPS).

Comment 21

[Alex Gibson [:agibson]]

Attachment: firstrun-cpu.png

Comment 22

[Alex Gibson [:agibson]]

Changing this line from position: fixed to position:absolute seems to help things greatly: https://github.com/mozilla/bedrock/blob/master/media/css/firefox/firstrun/firstrun-quantum.scss#L59

Comment 23

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub pull-request: https://github.com/mozilla/bedrock/pull/5526

Comment 24

[[github robot]]

Commit pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/0c2920103f1d0dc3fbafdad9df5c0bb7a84a5e3a
Bug 1417888: Firstrun performance

- remove SVG background images and replace with tail wave from /new
  - this image is at the top of the page so I also removed the code that
    vertically centers the text and login
- edit SVG to remove tiny gaps between blue, light blue, and white paths
- update media query governing switch from vertical to horizontal
  display
    - so you can still scroll with a tall narrow monitor