Open Bug 1241165 Opened 7 years ago Updated 7 years ago

DOM/CSS animations much slower on current and nightly FF than FF 16


(Core :: CSS Parsing and Computation, defect)

43 Branch
Not set




(Reporter: donrhummy, Unassigned)


(Depends on 1 open bug)


(Whiteboard: performance)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20160105164030

Steps to reproduce:

Tested three different pages on the same computer using both Firefox 16 and Firefox 43 and Firefox 46:



Linux 3.16.7
openSUSE 13.2
AMD A4-3400 APU with Radeon(tm) HD Graphics (Dual Core) 
1080P Monitor using Catalyst driver

(I installed FF16 from Mozilla's archive of old versions)

Actual results:

On Firefox 43 and 46, #1 and #2 were both very, very slow (#1 was 4.7 FPS) and #3 was semi-slow.

On Firefox 16, #1, #2 were more than twice as fast (#1 was 13 FPS).

Expected results:

The more recent FF versions should have been faster, not slower.
Product: Firefox → Core
Performed some tests on Ubuntu, both x86 and x64. While I didn't notice a remarkable difference between FF16 and FF43, there is a noticeable difference between FF43 and FF46. Assigning the issue to DOM: Animation as a starting point for this issue.

16.0   User Agent Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20100101 Firefox/16.0
43.0.4 Build ID 20160105164030 Mozilla/5.0 (X11; Linux i686; rv:43.0) Gecko/20100101 Firefox/43.0
46.0a1 Build ID 20160124030209 Mozilla/5.0 (X11; Linux i686; rv:46.0) Gecko/20100101 Firefox/46.0
16.0   Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0
43.0.4 Build ID 20160105164030  User Agent Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0
46.0a1 Build ID 20160121030208 User Agent Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0

1. - jquery engine

FF16:  avg. 31fps  - tops at 35fps
FF43: avg. 35fps  - tops at 39.4fps
FF46: avg. 18fps  - tops at 19.3fps 

FF16:  avg. 0.6fps  - tops at 0.9 fps
FF43: avg. 1.3fps  - tops at 1.9 fps
FF46: avg. 0.9fps  - tops at 1.8 fps

FF16:  avg. 38fps  - tops at 40.4fps
FF43: avg. 42fps  - tops at 44.6fps
FF46: avg. 20fps  - tops at 21.4fps

FF16:  avg. 0.7 fps  - tops at 1.0fps
FF43: avg. 1.8 fps  - tops at  2.2fps
FF46: avg. 1.3 fps  - tops at  1.5fps

Chrome: avg.  45fps - tops at  55fps    
Chrome: avg. 6.8 fps - tops at 7.2 fps 


FF16: 220+fps
FF43: 220+fps
FF46: 220+fps

FF16: +230fps
FF43: +230fps
FF46: +230fps

Chrome: 230+fps


FF16: 210 + fps
FF43: 230 + fps
FF46: 80-120 + fps

FF16:  +220 fps
FF43:  + 220fps
FF46:  + 90fps

Chrome: 180+ fps
Component: Untriaged → DOM: Animation
Ever confirmed: true
Whiteboard: performance
This doesn't appear to be related to CSS animations or Web Animations. jQuery doesn't use CSS transitions or CSS animations or Web Animations (and the Zepto animations, which *do* use CSS transitions, according to the web page, seem smooth).
Component: DOM: Animation → DOM
Adrian, did you test Nightly (FF46) with e10s enabled or disabled?
Flags: needinfo?(adrian.florinescu)
I did. Turning off e10s on FF46, added 5-10% at most performance gain.
Flags: needinfo?(adrian.florinescu)
For there is definitely an issue with e10s enabled.
Without e10s I get ~60fps (FF46, 64bit Linux), with e10s ~30fps
Profiling on non-e10s Nightly
(1 ) non-e10s case is largely reflow and style (setting getting .left/.top etc).

(2) is perhaps less interesting. There refresh driver ticks and paints as expected.
JS takes some time and .left/.top shows up again.

(3) is even more about painting and refreshdriver, which is expected when doing animations in JS. 2d canvas operations aren't showing up too badly in the profile.

Based on (1), ->CSS, although this is also about layout.

(But now testing e10s. Need to file a separate bug for that.)
Component: DOM → CSS Parsing and Computation
related to comment#4

When I tested to reproduce, I thought I turned E10s off by using NewNonE10s Tab option. Using NewNonE10s tab induces only a variance of 2-3 fps, which i considered negligible in the first tests ran.

Turning off E10s for the whole browser from preferences confirms :smaug's #comment5, and the difference is nearly double between NonE10s and E10s for Nightly46.

My question is if the NewNonE10s Tab option shouldn't function the same as the browser restarted with E10s off?
(In reply to Adrian Florinescu [:AdrianSV] from comment #7)

> My question is if the NewNonE10s Tab option shouldn't function the same as
> the browser restarted with E10s off?
New bug logged which covers this: Bug 1243297
You need to log in before you can comment on or make changes to this bug.