Open Bug 722186 Opened 8 years ago Updated 5 years ago
poor canvas performance (compared to Chrome) when drawing lines
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.
Way slower on Win7 w/ D2D as well. Maybe bz can profile it.
OS: Linux → All
Hardware: x86_64 → All
Version: 12 Branch → Trunk
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.
(this is a hidden pref, you have to create it)
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
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).
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.
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..
(In fact on this box, Skia/Azure FF nightly is noticeably faster than latest Chrome). I will investigate Linux tomorrow
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.
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.
Whiteboard: [cairo path code]
This is a lot faster with Skia, but always a bit slower than Chrome.
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.
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.
(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.
I see that bug 702158 is fixed now. Will it be time to retry with tomorrow's nightly?
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.
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.
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?
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.
Anything related to this bug ? Why is it not a high priority ?
(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.
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.
You need to log in before you can comment on or make changes to this bug.