Much slower animation in Firefox Nightly than in Chromium 22

RESOLVED WONTFIX

Status

()

Core
Graphics
RESOLVED WONTFIX
6 years ago
6 years ago

People

(Reporter: nemo, Unassigned)

Tracking

Trunk
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

6 years ago
Not sure if this is JS or rendering (although layers acceleration did not help)  but anyway, fairly self-explanatory.

Fired up Chromium to compare after reading notice at bottom of page recommending it.

BTW, the site looked pretty cool last night w/ the clearly defined hurricane eye over new jersey.

Ran into the link off of news.ycombinator.com
Fwiw, it looked about the same on Chrome and Nightly for me on Mac.  So I'm somewhat dubious that it's a JS engine issue.  But maybe I just have a faster machine so it wasn't relevant that the JS took longer...

nemo, want to do a profile here?
I profiled this under OS X 10.7, and on first glance it looks like most time is spent in or under various mozilla::gfx and mozilla::dom functions:
http://people.mozilla.com/~bgirard/cleopatra/?report=03975325468ac81ea3658cdf4840b456629446d9

Having said that, the site runs pretty smoothly for me, so this might not be comparable to the Linux situation at all.
Yeah, so that profile shows 11% of the time setting stroke styles (parsing colors from strings), 6% beginPath, 9% moveTo, and 38% stroke() as the main things that take up time.

Stroking on Mac (which uses CoreGraphics directly) is blinding fast compared to Linux (cairo+pixman) last I checked, so I would not be surprised if Linux is completely gated on pixman here.  See all the bugs that have "cairo path" in their whiteboard.  That said, profile still needed to verify that.
Assignee: general → nobody
Component: JavaScript Engine → Graphics
It's pretty smooth on windows, which is surprising as D2D isn't the very best at stroking, perhaps these are simple for D2D somehow. It does swallow up a full CPU core :).
It does that for me on Mac too, both in Chrome and in Firefox.

Comment 6

6 years ago
I tested on Windows and Linux. On Windows (D2D) it is super smooth. On Linux, it was not that bad (on a fairly decent machine, though). Changing the canvas backend from Cairo to Skia made things better (Skia often has better performance on stroking than Cairo), so this supports the hypothesis that we are being bogged down by Cairo stroking. In all cases I max out a core with this.

Nemo: could you try switching your canvas backend to Skia (change gfx.canvas.azure.backends to "skia" and restart) and see if you get improved (as good as Chrome) performance please?
Flags: needinfo?(bugs)
(Reporter)

Comment 7

6 years ago
Yep. Switching to skia made a huge difference.
Awesome. Thanks.
Flags: needinfo?(bugs)
(Reporter)

Comment 8

6 years ago
FWIW, skia didn't make any difference in bug #803621 on this ATI Linux machine (which was still stuttery and completely screwed up).

Oh, and I didn't try this wind thing on the initial machine I reported against yet.  That one was Nvidia+Linux, this one is ATI+Linux.  I'll try it tonight, but presumably it'll respond the same way :)

Comment 9

6 years ago
Cool, that pretty much confirms that it is the underlying graphics library that is holding us back here. Unfortunately there are other things where Cairo is faster than Skia, so we don't have plans at this stage to change to Skia by default. I'd be interested to hear the result for the other machine though.

Changing the canvas backend for bug 803621 won't make any difference because the test case does not use canvas.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 10

6 years ago
Yeah, I'd changed both content and canvas before checking.

So, maybe skia for canvas and cairo for content, if there's stuff cairo is faster at?
'cause, that speedup was pretty impressive.
unless you mean that cairo is faster at some canvas stuff, which seems odd - it isn't like there's that much to canvas. :)

Comment 11

6 years ago
(In reply to nemo from comment #10)
> Yeah, I'd changed both content and canvas before checking.
> 
> So, maybe skia for canvas and cairo for content, if there's stuff cairo is
> faster at?
> 'cause, that speedup was pretty impressive.
> unless you mean that cairo is faster at some canvas stuff, which seems odd -
> it isn't like there's that much to canvas. :)

There is some canvas stuff that Cairo is faster at - it seems to be faster at moving pixels around (blitting, 'texturing', etc.) whereas Skia is faster at stroking and some other stuff.

Content by default does not use Azure at all, you would need to set gfx.content.azure.enabled to true as well as setting the backend, but Azure content is work in progress so you may (probably) see rendering errors.
(Reporter)

Comment 12

6 years ago
Yeah, I'd set that one to true too :)  Actually, I'd set it in the past, and just forgotten to reenable when I reset this test profile.  I always remember to disable trimurls ofc :-p
Haven't seen any rendering errors yet (apart from the brokenness on this ATI card and the aforementioned bug)
One of these days we should convince the cairo folks to fix their path impl... :(
(Reporter)

Comment 14

6 years ago
And, yeah, wind map is all better on the Nvidia machine too, w/ skia
But you knew that already.
You need to log in before you can comment on or make changes to this bug.