Closed Bug 1241165 Opened 10 years ago Closed 7 months ago

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

Categories

(Core :: CSS Parsing and Computation, defect)

43 Branch
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: donrhummy, Unassigned)

References

Details

(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: 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.
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
Severity: normal → S3

No longer reproduces

Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.