David A. Madore Reporter
	Description • 13 years ago

The linked page (<URL: http://www.madore.org/~david/.tmp/e8nowebgl.html >) attempts to draw an animation consisting of 6720 lines of width 0.2 pixels on a 600×600 canvas at 25fps.  On Chrome this target rate is reachable with a reasonably recent PC running Linux, while Firefox only manages about 2fps on the same config.  (More precise timings show that Firefox is about 20 times slower than Chrome.)  It's really the line drawing operation which is slow, the other parts of the script take negligible amounts of time.  Actually, the Xorg process is the one taking most of the CPU.

Tested with today's Firefox-12 from mozilla-central (<URL: http://hg.mozilla.org/mozilla-central/rev/f35a3eb44138 >), about:support reports AzureBackend: skia (but I'm not sure whether I actually believe this, because Xorg taking all the CPU suggests that Xrender is being used, which I thought Skia didn't use, but I may be wrong).

PS: I realize there are already many bugs reporting poor canvas performance.  This one may be a duplicate, but I don't think so because (a) it's against Azure supposedly using the Skia backend on Linux, and (b) no other bug reports a factor 20 in performance wrt Chrome.

	Ryan VanderMeulen [:RyanVM]
	Comment 1 • 13 years ago

Way slower on Win7 w/ D2D as well. Maybe bz can profile it.

	Benoit Jacob [:bjacob] (mostly away)
	Comment 2 • 13 years ago

While Skia is the default Azure backend, using Azure is not enabled by default. You're most probably still using Cairo here.

Please try with this preference in about:config :
gfx.canvas.azure.enabled = true

@ Ryan: bz's time is worth too much to ask him running a profiler for you :)

CC'ing some relevant people.

	Benoit Jacob [:bjacob] (mostly away)
	Comment 3 • 13 years ago

(this is a hidden pref, you have to create it)

	Benoit Jacob [:bjacob] (mostly away)
	Comment 4 • 13 years ago

Here on Ubuntu 11.10 / x86_64 / radeon driver, my results:
 - Firefox 12 is equally slow with or without gfx.canvas.azure.enabled at ~ 2 FPS
 - chromium-browser is even slower by an order of magnitude, at ~ 0.2 FPS

a bit outdated though:
chromium-browser --version
Chromium 15.0.874.106 Ubuntu 11.10

	David A. Madore Reporter
	Comment 5 • 13 years ago

I tried with gfx.canvas.azure.enabled set to true, and could see no noticeable difference.  In fact, I could see no noticeable effect at all (I tried restarting, of course).  Xorg still takes most CPU, so I still suspect it's Cairo-over-XRender: how can I check whether Azure is being used?

The Chromium version I'm comparing with is almost exactly the same as you report (I have Chromium 15.0.874.121 Debian wheezy/sid), so I'm very confused as to what the difference may be.  I'm also on x86_64 with radeon drivers (Debian wheezy running Linux 3.1.10).

	Benoit Jacob [:bjacob] (mostly away)
	Comment 6 • 13 years ago

Not sure how to check if Azure/Skia is being used, aside from using a debugger. I too get exact same results regardless of that pref and suspect it's not taking effect.

	George Wright (:gw280) (needinfo me!)
	Comment 7 • 13 years ago

It's fast on my OS X machine running the Skia/Azure backend. Not sure about the framerate though, but it's definitely faster than 2fps - looks more to be around 20..

	George Wright (:gw280) (needinfo me!)
	Comment 8 • 13 years ago

(In fact on this box, Skia/Azure FF nightly is noticeably faster than latest Chrome). I will investigate Linux tomorrow

	Benoit Jacob [:bjacob] (mostly away)
	Comment 9 • 13 years ago

Here's a profile I took with perf on linux 3.0.

It shows that we're spending our time in Cairo. The preference gfx.canvas.azure.enabled doesn't have any effect, actually it was enabled when I took that profile. (about:support says azure backend = skia so I guess azure isn't being used at all).

Specifically:

 - we're spending time computing sines, called from Cairo called from gfxContext::Stroke().
 - we're spending more time computing sines, called from somewhere else (could be JITted JS, but the JS here doesn't seem to be computing that many sines. So maybe it's still Cairo and perf just doesn't get it).
 - we're spending time in _cairo_bentley_ottmann_tessell
 - also spending time in _add_clipped_edge and csloww and _cairo_surface_composite_trapezoids called from gfxContext::Stroke()
 - also spending time in some kernel functions that perf doesn't know about. Anyone knows how to get kernel symbols on ubuntu? Never saw that problem on debian.

	Boris Zbarsky [:bzbarsky]
	Comment 10 • 13 years ago

Fwiw, anything involving line-drawing performance on Windows and Linux when using cairo is likely to be cairo's path code, which we don't actually use on Mac anyway.  So asking me to profile it is likely to just end up with me saying I don't see the original performance problem.  ;)

Luckily, comment 9 covers the profiling bits.

	Marco Castelluccio [:marco]
	Comment 11 • 13 years ago

This is a lot faster with Skia, but always a bit slower than Chrome.

	Marco Castelluccio [:marco]
	Comment 12 • 13 years ago

Sorry, forgot to mention I did the test with a debug build. So a release build should be faster and probably as fast as (if not faster) than Chrome.

	Benoit Jacob [:bjacob] (mostly away)
	Comment 13 • 13 years ago

Marco, how did you manage to get Firefox to use Skia? As I noted on comment 10, even with gfx.canvas.azure.enabled, for me it's still using Cairo.

	Marco Castelluccio [:marco]
	Comment 14 • 13 years ago

(In reply to Benoit Jacob [:bjacob] from comment #13)
> Marco, how did you manage to get Firefox to use Skia? As I noted on comment
> 10, even with gfx.canvas.azure.enabled, for me it's still using Cairo.

Yes, there was a problem, I've uploaded a new patch in bug 702158 that correctly enables Skia.

	Benoit Jacob [:bjacob] (mostly away)
	Comment 15 • 13 years ago

I see that bug 702158 is fixed now. Will it be time to retry with tomorrow's nightly?

	David A. Madore Reporter
	Comment 16 • 13 years ago

Tested with revision http://hg.mozilla.org/mozilla-central/rev/a71b7cea4577 and gfx.canvas.azure.enabled set to true and Firefox is, indeed, just about as fast as Chrome on this example on my PC.  I guess this bug can be closed, then.

	Benoit Jacob [:bjacob] (mostly away)
	Comment 17 • 13 years ago

Thanks for testing. I would keep this bug open until the _default_ rendering path is fast. So now we know we could in particular close this bug if we switched to Skia by default.

	David A. Madore Reporter
	Comment 18 • 12 years ago

Hmmm, I wanted to check how this was coming along, I tried with Firefox 15.0b3 (<URL: http://hg.mozilla.org/releases/mozilla-beta/rev/a70fc44b8c68 > to be exact) on Ubuntu 11.10, and now canvas displays nothing at all when gfx.canvas.azure.enabled==true.  Should I check the nightlies and file another bug for this, or is activating gfx.canvas.azure.enabled on Linux still considered highly-experimental-not-worth-bug-reporting-for?

	Boris Zbarsky [:bzbarsky]
	Comment 19 • 12 years ago

If it's happening in a nightly from July 28 or later (i.e. one that has a fix for bug 764125) then it's worth filing a bug on.

	Mostafa
	Comment 20 • 9 years ago

Anything related to this bug ? Why is it not a high priority ?

	Jeff Muizelaar [:jrmuizel]
	Comment 21 • 9 years ago

(In reply to Mostafa from comment #20)
> Anything related to this bug ? Why is it not a high priority ?

Currently, regressions are a higher priority.

	Milan Sreckovic [:milan] (needinfo for best results)
	Comment 22 • 9 years ago

Not sure if fixing this would show up as a benefit of Shumway, but that would still be going the Skia route and OS X.