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

NEW
Unassigned

Status

()

3 years ago
3 years ago

People

(Reporter: donrhummy, Unassigned)

Tracking

(Depends on: 1 bug)

43 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: performance)

(Reporter)

Description

3 years ago
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:

1. https://greensock.com/js/speed.html
2. http://phrogz.net/tmp/image_move_speed_css.html
3. http://phrogz.net/tmp/image_move_speed_canvas.html

Computer:

Linux 3.16.7
openSUSE 13.2
AMD A4-3400 APU with Radeon(tm) HD Graphics (Dual Core) 
12 GB RAM
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.

Updated

3 years ago
Component: Untriaged → Untriaged
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.


x86
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
x64
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. https://greensock.com/js/speed.html - jquery engine
x86

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

1000DPS:
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


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

1000DPS:
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 



2. http://phrogz.net/tmp/image_move_speed_css.html

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


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

Chrome: 230+fps

3. http://phrogz.net/tmp/image_move_speed_canvas.html

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

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

Chrome: 180+ fps
Status: UNCONFIRMED → NEW
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 https://greensock.com/js/speed.html 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 )https://greensock.com/js/speed.html non-e10s case is largely reflow and style (setting getting .left/.top etc).


(2) http://phrogz.net/tmp/image_move_speed_css.html is perhaps less interesting. There refresh driver ticks and paints as expected.
JS takes some time and .left/.top shows up again.


(3) http://phrogz.net/tmp/image_move_speed_canvas.html 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.