bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

[APZ] Performance regression in CSS-animation-heavy interactive text




3 years ago
8 months ago


(Reporter: kael, Unassigned)


(Blocks: 1 bug, {perf, regression})

39 Branch
Windows 8.1
perf, regression
Dependency tree / graph

Firefox Tracking Flags

(e10s-, firefox47 wontfix, firefox48 fix-optional, firefox49+ wontfix, firefox50 fix-optional)


(Whiteboard: [gfx-noted], URL)


(6 attachments)



3 years ago
I revisited one of my old experiments in the latest rev of Developer Edition and the performance is catastrophically bad compared to how it was before. I previously filed a bug about an issue that affected it - bug #1046055 - and had implemented a workaround for that. With the workaround (and with the fix) performance was great.

Now, performance is generally kind of stuttery, and if you scroll down rapidly the whole browser hangs. This didn't happen before and *shouldn't* happen; the code makes attempts to ensure that it doesn't. Scrolling works as intended in IE (perfectly, very smooth) and just fine in Chrome.

The intended behavior is that scrolling instantly skips through the document to the point of your scroll then resumes animating, without judder or perf degradation.
I think this might be more of a layout/layerization issue. What do you think Matt?
Flags: needinfo?(matt.woodrow)
Whiteboard: [gfx-noted]

Comment 2

2 years ago
Not sure if this is an issue with both JavaScript mixed with CSS styles but in my work environment our network monitoring software (Science Logic EM7) runs decent on first login.  But degrades very rapidly until pages stutter pop windows open slower and saves take forever.

Comment 3

2 years ago
Created attachment 8758638 [details]
Performance Profile while manipulating heavy CSS/Javascript event page.

Comment 4

2 years ago
Created attachment 8758640 [details]
Additional performance profile while using same environment

Comment 5

2 years ago
[Tracking Requested - why for this release]:
status-firefox49: --- → ?
tracking-e10s: --- → ?
tracking-firefox49: --- → ?
Tracking 49+ because of the nature of this regression - this bug still needs an owner - Matt are you the correct person to investigate? Thanks.
status-firefox49: ? → affected

Comment 7

2 years ago
(In reply to Marcia Knous [:marcia - use ni] from comment #6)
> Tracking 49+ because of the nature of this regression - this bug still needs
> an owner - Matt are you the correct person to investigate? Thanks.

I created a new bug for my issue before I found this. I am not 100% sure my bug is related but its sounds very similar performance wise.  Same performance profiles attached. https://bugzilla.mozilla.org/show_bug.cgi?id=1277206
tracking-firefox49: ? → +
I can't reproduce this on OSX on Nightly, performance is really good there, this might be Windows specific.
Flags: needinfo?(matt.woodrow)
Keywords: regressionwindow-wanted

Comment 9

2 years ago
It's fine on Windows for me in x64 dev edition, so it may've been fixed recently?


2 years ago
tracking-e10s: ? → -
I can't reproduce either on Win10. However, scrolling in my Ubuntu VM (Basic Compositor) is still pretty terrible.
User Agent:  Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Firefox: 50.0a1, Build ID: 20160701030235

I have tested this issue on Ubuntu 14.04 x64 and Windows 8.1 x64 on the latest Nightly(50.0a1) build.
I've managed to reproduce it and performed a regression on both OSs. 

This are the results on Ubuntu 14.04: 

Last good revision: 077a6b1a1ba5abd927990e01740806c76f899f9b
First bad revision: 30742281c223e2a7abb5931ee5383d890b5ce0e8

This are the results on Windows 8.1 x64:

Last good revision: 738d8ee106fe760c44f54b5f250d0b36a84818c8
First bad revision: af67b5f73381f154f41ded5926d823709a0ebd08
INFO: Pushlog:
Keywords: regressionwindow-wanted → regression


2 years ago
Keywords: perf


2 years ago
Blocks: 1157745, 1143856
+NI to make sure kats sees comment 11.
Flags: needinfo?(bugmail)
(In reply to Emil Pasca from comment #11)
> This are the results on Windows 8.1 x64:
> Last good revision: 738d8ee106fe760c44f54b5f250d0b36a84818c8
> First bad revision: af67b5f73381f154f41ded5926d823709a0ebd08
> INFO: Pushlog:
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=738d8ee106fe760c44f54b5f250d0b36a84818c8&tochange=af67
> b5f73381f154f41ded5926d823709a0ebd08

Can you attach your about:support information from the windows build that reproduces this problem? On my Windows tablet I can't repro any bad behaviour while scrolling down on the page in the URL field.
Flags: needinfo?(bugmail)
Flags: needinfo?(emil.pasca)
Created attachment 8767867 [details]

Attached windows_8.1_troubleshooting_information.
Flags: needinfo?(emil.pasca)
Nothing there looks out of the ordinary. Do you have access to a Windows 10 machine that you can try reproducing this on? I wonder if it's just a Windows 8 vs Windows 10 issue.
Flags: needinfo?(emil.pasca)

Comment 17

2 years ago
Build Identifier:
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0 ID:20160705030222

I can reproduce the performance regression in Nightly50.0a1 Windows10 if enabled APZ.
This performance regression appears regardless of HWA enabled/disabled.
Summary: Catastrophic performance regression in CSS-animation-heavy interactive text → [APZ] Catastrophic performance regression in CSS-animation-heavy interactive text
Thanks. I am still unable to reproduce on my Windows 10 device with APZ enabled. Just to confirm, the STR I'm using is:

1. Click on the link in the URL field of this bug
2. Scroll down a bunch (I've tried scrolling down to different places in the page)

In all cases, when I stop scrolling, the text starts animating in one letter at a time, and it looks pretty nice (although I also get the quotation marks always visible, which looks kind of odd). After it fills the visible screen area it pauses the animation and I have to scroll down more to get it continue animating. After I scroll down to the very bottom everything is done and I can scroll around no problem.
Flags: needinfo?(emil.pasca)

Comment 19

2 years ago
1. OPEN URL field of this bug
2. Press [SPACE] key to start drawing texts 

Actual results: 
Rendering is slow down about 40-50% if APZ is enabled

See screen capture: https://youtu.be/LZkZaNSiWr8
Performance comparison between APZ on and APZ off.
Ah, thanks! I was thinking there would be stuttery performance / browser hangs as described in comment 0. I can do some profiling on this tomorrow and see what's causing the slowness. ni myself so I don't forget.
Flags: needinfo?(bugmail)
Based on a profile I got, I suspect we are creating a lot of ContainerLayers when APZ is enabled.

Created attachment 8768897 [details]
Displaylist dump with APZ on

Ok, so from what I can make out, each character that animates in is initially set to opacity:0, but when event-regions are enabled, they get a nsDisplayOpacity which contains a event regions item and a text item. These all end up creating inactive layer managers during processing and then it all gets flattened back into a relatively simple final layer tree.

With APZ enabled, the displayport area is of course larger and so it takes even more time. I'm attaching a display list dumps with APZ on, APZ off but event regions on, and APZ and event regions off which illustrate the problem.
Flags: needinfo?(bugmail)
Created attachment 8768898 [details]
Log with APZ off / Event regions on
Created attachment 8768899 [details]
Log with APZ off / Event regions off
So in the end I think this is basically expected behaviour given how the page is constructed and how we handle opacity. Because opacity:0 stops elements from painting but keeps them participating in event dispatch, we need to build the event regions to ship over to the compositor. If the opacity:0 were accompanied by pointer-events:none then we wouldn't have to do this and things would behave much better.

Our other option is to try to optimize the "opacityItemForEventsOnly" codepath at [1], which is probably going to be difficult.

Given that the user-visible impact here is just slower animation, and not browser hanging/crashing as described in comment 0, I don't think this is super urgent to fix. Authors should be able to pointer-events:none on the hidden characters as a workaround.

[1] http://searchfox.org/mozilla-central/rev/a7c8e9f3cc323fd707659175a46826ad12899cd1/layout/generic/nsFrame.cpp#2193
Blocks: 1157834
Component: Graphics: Layers → Layout
Priority: -- → P3
I think we could fix this if we wanted to.

When we get to BuildDisplayListForStackingContext for an opacity:0 with event regions, we could skip creating the new event regions item (so all added regions go into the existing regions item). We'd also have to block recursive calls to this and BuildDisplayListForChild creating event regions items.

Once we finish building the child display list (which should only contain real items, not event regions), we can just discard it instead of wrapping it in an nsDisplayOpacity.

Comment 27

2 years ago
pointer-events: none being necessary for good rendering performance is really surprising to me. I've never seen it messaged to anyone in documentation or as developer best practices wisdom. If it's a new problem that's been introduced recently, an effort to communicate it to people seems necessary, at the very least.

I don't think I've ever encountered pointer-events: none in the wild except in cases where people specifically wanted to block mouse events from hitting an element.

I do think the bad behavior here is less severe than it was when I reported the issue though. It makes the behavior unpleasant but doesn't cause the browser to severely degrade or hang (unless you count mobile, where this sort of stuff is unusably bad anyway no matter which browser you use). If the pointer events hack is messaged to developers they'll eventually pick up on it.
status-firefox48: --- → fix-optional
status-firefox50: --- → affected
Summary: [APZ] Catastrophic performance regression in CSS-animation-heavy interactive text → [APZ] Performance regression in CSS-animation-heavy interactive text
status-firefox47: --- → wontfix
Hi :milan,
Do you think is there anyone in your team can help to investigate this issue or take this while kats is on PTO?
Flags: needinfo?(milan)
(In reply to Gerry Chang [:gchang] from comment #28)
> Hi :milan,
> Do you think is there anyone in your team can help to investigate this issue
> or take this while kats is on PTO?

kats wouldn't likely be doing it; we would deal with this in layout - see comment 26 - but sitting on the outside, it isn't clear to me how urgent that work would be.  Maybe Jet has a feeling about the priority.
Flags: needinfo?(milan) → needinfo?(bugs)

Comment 30

2 years ago
(In reply to K. Gadd (:kael) from comment #27)
> pointer-events: none being necessary for good rendering performance is
> really surprising to me. 

We agree that this is incorrectly functioning, but offer an easy workaround (pointer-events: none) if your use-case needs it. The fix proposed in comment 26 may take more time to put together, but the workaround should help you get good performance in Firefox right away.
Flags: needinfo?(bugs)
We are heading into beta 7 now so it's a bit late. We could still take a low risk fix. Seems ok to aim this at 50 or 51 given we have a workaround.
status-firefox49: affected → fix-optional


2 years ago
status-firefox50: affected → fix-optional
status-firefox49: fix-optional → wontfix
You need to log in before you can comment on or make changes to this bug.