806975 - Much slower animation in Firefox Nightly than in Chromium 22

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[nemo]

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

Comment 1

[Boris Zbarsky [:bzbarsky]]

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?

Comment 2

[Till Schneidereit [:till]]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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.

Comment 4

[Bas Schouten (:bas.schouten)]

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 :).

Comment 5

[Boris Zbarsky [:bzbarsky]]

It does that for me on Mac too, both in Chrome and in Firefox.

Comment 6

[Nick Cameron [:nrc]]

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?

Comment 7

[nemo]

Yep. Switching to skia made a huge difference.
Awesome. Thanks.

Comment 8

[nemo]

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

[Nick Cameron [:nrc]]

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.

Comment 10

[nemo]

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

[Nick Cameron [:nrc]]

(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.

Comment 12

[nemo]

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)

Comment 13

[Boris Zbarsky [:bzbarsky]]

One of these days we should convince the cairo folks to fix their path impl... :(

Comment 14

[nemo]

And, yeah, wind map is all better on the Nvidia machine too, w/ skia
But you knew that already.