Open Bug 561361 Opened 10 years ago Updated 4 years ago
Poor performance with Canvas and Linux
I think it happens because linux gecko is using system X pixman, and I'm not sure that combined composite/rotate/scale combination is fast on pixman :(, also it probably doing image rendering fallback path. which is even more slower..., and there are no such problem on windows... Chrome work faster because it using its own compositor (and probably rendering stuff on client side.). Using image surface for rendering or canvas layers with HW accelerated rendering should help
We have an existing bug on using an image surface instead of an X one for canvas. This should probably depend on that, if not be a duplicate.
Boris, which bug?
We are currently slower than Chrome, and even Epiphany (which uses Cairo AFAICT), while scrolling the github network graph on Linux. The same does not seem to be the case on OS X. This is probably because of how we're using Cairo, since both Epiphany and Firefox use Cairo; however, Epiphany uses Ubuntu's system cairo, while we use our builtin, so it's possible that there's something in their cairo that we don't have. I'm going to check a system cairo build of mozilla-central to see if there's any difference.
With system Cairo, Firefox didn't get any better. (Strangely, Epiphany got a lot worse after I recompiled Ubuntu's Cairo to include support for the tee surface.) So this must be a problem with the way we use Cairo.
We should try now that Skia for Linux has landed.
Testing with a Skia build. For the page mentioned in comment 0, it's totally faster. Yeah! Not as smooth as chrome, but we jumped from "almost 0 fps" to ~20fps, while chrome is ~25fps (not real number, just to give an idea of the progression).
Mozilla/5.0 (X11; Linux x86_64; rv:13.0a1) Gecko/20120201 Firefox/13.0a1 Here's the URL from that screencast if anyone wants to test. https://github.com/mojombo/ernie/network It seems like a good testcase and is certainly pretty slow for me. Unfortunately I didn't get to see the amazing speed increase that Paul saw in comment 7 because it crashes instantly with gfx.canvas.azure.enabled = true :-( I'll file a new bug for that.
Paul, are you on a 32bit machine?
Hm. That crash there is in the font stuff right? That reminds me of the way gnome-shell crashes for me on this fglrx (yes, I know, but only thing that works on my ATI card) driver. Which seems to also be in font rendering. http://m8y.org/tmp/gnome-shell-crashes/ So, maybe not same issue as comment #8. Anyway, probably is better in some new bug and maybe just blacklisting my poor video card.
If you want, you can try compiling with this patch (that should temporarily solve the crash): https://bugzilla.mozilla.org/attachment.cgi?id=593549
Cool. Will have to give it a shot. And, yeah, the crash is regardless of machine or driver or graphics card. Sooo, not related to my other prob I 'spose.
Another URL for demonstrating the slow canvas performance on Linux 'desktop' kernel: http://kevs3d.co.uk/dev/asteroids/ tested with: openSUSE 11.4 kernel 18.104.22.168-0.11-desktop #1 SMP PREEMPT Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0 Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 works fast on Windows, works fast on Linux with Chrome, always used to work fast on Linux with Firefox (3.6+) in the past, works fast with openSUSE 11.4 kernel 22.214.171.124-0.11-default #1 SMP Interestingly, the 'desktop' kernel does come with all sorts of 3D effects (Compositing), but these are disabled with the 'default kernel.
I think that the drawing speed is only part of the problem and the smaller one. The other part is that there is some kind of timeout before the canvas is drawn on-screen. With back-to-back mousemove events that timeout is never reached and the visual state may remain unchanged for many seconds if you keep moving the pointer around. (Or possibly the back-to back events are queued and dispatched but there is no rendering happening between them) Here is a quick test case: http://zezo.org/ctest.html Move the mouse around and see how many lines appear at once after you stop moving it. If called like this: http://zezo.org/ctest.html?timeout the drawing function is dispatched via setTimout(...,0) and while the performance still is not stellar, the interactive response is much better.
> > http://zezo.org/ctest.html > For this test I see lot of CPU time wasted somewhere in JS autogenerated code, 61% CPI 20 2.1030 libxul.so qmozembedtest pixman_composite_over_8888_0565_asm_neon 23 2.4185 libxul.so qmozembedtest pixman_composite_src_8888_8888_asm_neon 23 2.4185 Xorg Xorg /usr/local/XSGX/bin/Xorg 587 61.7245 anon (tgid:3316 range:0x43f9d000-0x43fad000) qmozembedtest anon (tgid:3316 range:0x43f9d000-0x43fad000)
I created a jsfiddle http://jsfiddle.net/7dxDu/1/ test under ubuntu 12.10/64 bits: firefox 15 results: 3.180s for the "ctx.beginPath(); ctx.closePath();" loop 5.350s for the "ctx.stroke();" loop chromium 18 results: 0.351s for the "ctx.beginPath(); ctx.closePath();" loop 0.235s for the "ctx.stroke();" loop this is a real problem to be more than 10 times slower than other browsers... the canvas quickly becomes unusable under firefox when drawings stop being simple and get a little heavy...
on my portable pc under windows seven it's even worse: firefox 14 results: 16.379s for the "ctx.beginPath(); ctx.closePath();" loop 32.459s for the "ctx.stroke();" loop chromium 23 results: 0.378s for the "ctx.beginPath(); ctx.closePath();" loop 0.305s for the "ctx.stroke();" loop
(In reply to sfornengo from comment #18) > on my portable pc under windows seven it's even worse: > > firefox 14 results: > 16.379s for the "ctx.beginPath(); ctx.closePath();" loop > 32.459s for the "ctx.stroke();" loop > > chromium 23 results: > 0.378s for the "ctx.beginPath(); ctx.closePath();" loop > 0.305s for the "ctx.stroke();" loop Please open a new bug for this, writing the contents of the Graphics section in about:support.
If you do file a bug for that, please provide a testcase that's closer to what your application actually does, i.e. not just a million calls that don't actually draw anything. Thanks.
ok, I agree. my real application draw a mesh of triangles (about 10000) on multiples canvas using ctx.moveTo and ctx.lineTo, then some vertices with ctx.arc and some other small things and finally allows to position it on a background image with mouse dragging. I simplify just drawing 10000 times the same triangle in only one empty canvas and here a testcase: http://jsfiddle.net/7dxDu/6/ under firefox the dragging is lagging... we can see that the draw() function benchmark is about 3 times slower under firefox than under chromium. all is very smooth under chromium even with 10 times more triangles.
sorry, use the following test case, sorting out of the loop the ctx.beginPath(); http://jsfiddle.net/7dxDu/8/
OK, please put it in its own bug. Thanks.
Oh, you did: bug 787679.
I wrote a more simple testcase: http://jsfiddle.net/7dxDu/9/ firefox: test1: 0.403s test2: 1.711s test3: 3.752s chromium: test1: 0.003s test2: 0.005s test3: 0.008s we can notice that firefox don't scale linearly as we could expect... doubling from 1000 to 2000 the number of triangles take 4 times longer to render ! chromium is blazingly fast as compared and scale linearly as expected.
please, see this testcase: (adjust var n=3000 if test is too slow on your machine)... http://jsfiddle.net/7dxDu/11/ this is really weird and incomprehensible, putting the ctx.beginPath() and ctx.stroke() inside the for loop is 10 times FASTER ! so the firefox problem seems to be on accumulating a path before stroking.
It seems that from firefox version 11 performance is more than 10 times lower than in previous versions of firefox: http://jsperf.com/batching-line-drawing-calls
(In reply to sfornengo from comment #27) > It seems that from firefox version 11 performance is more than 10 times > lower than in previous versions of firefox: > http://jsperf.com/batching-line-drawing-calls I also see considerable regressions on the latest versions.
Just stumbled onto this bug as well. See question on SO : http://stackoverflow.com/questions/14486910 TL;DR: I mostly see performance drops when rendering on the "mousemove" event, and only with Firefox on Linux. Everything else is more or less okay.
fx.thomas - try w/ gfx.canvas.azure.backends;skia ?
Using nightly 27.0a1 (2013-09-24) on archlinux 64-bit. I changed gfx.canvas.axure.backends to skia and noticed a huge improvement. Results from http://jsfiddle.net/7dxDu/9/ went from around 5.5 seconds on test3 to the following: test1: 0.004s test2: 0.007s test3: 0.01s This is actually faster than the chromium 29.0.1547.76 (223446) on my system. I'm hoping to find similar improvements with SVG performance.
Using nightly 29.0 a1 (and skia) 64bit on linux. I also get good results: nightly(cairo): test1: 0.518s test2: 2.405s test3: 4.924s nightly(skia): test1: 0.005s test2: 0.009s test3: 0.011s chromium (31.0.1650.57): test1: 0.004s test2: 0.007s test3: 0.011s The result seems simmular between chromium and firefox nightly (skia). However they don't get the same results with the following test page: http://www.kevs3d.co.uk/dev/asteroidsbench/ nightly (Cairo): Average FPS: 17 nightly (skia): Average FPS: 22 chromium (31.0.1650.57): Average FPS: 40
Its weird. Firefox ESR/GNU IceCat 31.2 (all plugins disabled) http://jsfiddle.net/7dxDu/9/ with Cairo backend freezes, taking over 6 seconds till "script hangs". with Skia test1: 0.007s test2: 0.015s test3: 0.02s However: http://ie.microsoft.com/testdrive/Performance/PsychedelicBrowsing/Default.html Cairo: 920-835 points Skia: 85 points With Cairo mouse jitters. With Skia mouse is very responsitive. So Cairo basically leads to surface acceleration on batch processes, where Skia leads to much less lags/timeouts between processes?
Also, here: http://jsperf.com/batching-line-drawing-calls/37 I get 46 events with skia, and 24 events with cairo.
http://www.kevs3d.co.uk/dev/asteroidsbench/ Cairo: Benchmark Score: 382 Average FPS: 8 Skia: Benchmark Score: 501 Average FPS: 11 This is Samsung R60plus (x300 IGP) with opensource radeon driver (kernel 3.17, mesa-dri 10.3.1-1).
Did a run on dev version of canvasmark: http://www.kevs3d.co.uk/dev/canvasmark/ 1. 285 354 2. 459 511 3. 223 281 4. 574 730 5. 224 306 6. 464 349 (!) 7. 228 263 8. 542 1175-985 cairo, skia skia is slower 30% only in 6 test, but twice fast in 8. legend: 1. asteroids bitmaps 2. asteroids vectors 3. asteroids bitmaps shapes text 4. asteroids shapes shadows blending 5. arena5 vectos shadows bitmaps 6. plasma math canvas shapes 7. 3d render math polygons image transforms 8. pixel blur get/put imagedata
Adding my voice to the choir - developing html5 games with FF in Linux can be a bit painful. Take a look at this raycasting example: http://gamemechanicexplorer.com/#raycasting-3 And then take a look at it in Chrome/ium. I get 15~19 fps with FF versus stable 60fps in Chrome :(
Otto, how'd FF do if you set gfx.canvas.azure.backends = skia in about:config ?
I tested it on two machines. Laptop is a 4 year old laptop, Core Duo with intel GMA. Desktop is a Pentium G2030 with a nVidia GTX 650 Ti using binary drivers. Both running Ubuntu 14.04 (Gnome - though I tried Fedora and regular Ubuntu with same results). I used http://gamemechanicexplorer.com/#raycasting-4 and www.html5-benchmark.com/ as benchmarks. Notebook had F33 installed (which has a big ass regression so I also tested with 35a2 on it). Notebook + Raycasting#4 + F33/F35a2: Cairo: ~19fps Skia: ~19fps Notebook + HTML5 Benchmark + F33: Cairo: score 221, cpu time 46.21s, lag 43179ms (yes, 43 seconds of lag). Skia: score 4772, cpu time 40.6s, lag 80ms. Notebook + HTML5 Benchmark + F35a2: Cairo: score 5763, cpu time 27.3s, lag 82ms. Skia: score 4816, cpu time 43.11s, lag 0ms (YES!). Desktop + HTML5 Benchmark + F35a2: Cairo: score 6146, cpu time 22.71s, lag 120ms Skia: score 5845, cpu time 26.73s, lag 76ms Desktop + Raycasting#4 + F35a2: Cairo: ~38 fps Skia: ~44 fps So, all in all, Skia does improve things but it is still very shy of the performance I get with Chrome or on Windows devices.
Nice, BTW, that FF35 test, was that with or without e10s?
Without - I'm running Aurora, not Nightly.
Arch Linux x86_64, Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz, Firefox-gtk3 36 b6, cairo backend: http://jsfiddle.net/7dxDu/9/ test1: 0.003s test2: 0.005s test3: 0.007s Opera 27: test1: 0.003s test2: 0.005s test3: 0.006s http://jsfiddle.net/7dxDu/11/ test1: 0.037s test2: 0.007s Opera 27: test1: 0.011s test2: 0.007s http://www.kevs3d.co.uk/dev/asteroidsbench/ Benchmark Score: 3218 Average FPS: 68 Opera 27: Benchmark Score: 3975 Average FPS: 83 http://html5-benchmark.com/ Score: 9909 Total CPU Time: 9.82s, Total Lag: 18ms Opera 27: Score: 8198 Total CPU Time: 14.88s, Total Lag: 0ms http://www.kevs3d.co.uk/dev/canvasmark/ CanvasMark Score: 12781 (Firefox 36 on Linux) Opera 27: CanvasMark Score: 13799 (Chrome 40 on Linux) As a conclusion: issue is solved?
So, FWIW: http://js1k.com/2013-spring/demo/1555 Is still horrendously slow in Linux if Skia isn't enabled in azure (that is, default configuration). There are a few similar JS/Canvas pages I've encountered with same problem. Just bringing this up 'cause of the prior comment and the generic nature of this bug description.
You need to log in before you can comment on or make changes to this bug.