Closed Bug 561361 Opened 14 years ago Closed 2 years ago

Poor performance with Canvas and Linux

Categories

(Core :: Graphics: Canvas2D, defect)

Product:
Core
Component:
Graphics: Canvas2D
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED INACTIVE

People

(Reporter: paul, Unassigned)

References

Details

Attachments

(1 file)

screencast: no skia vs. skia vs. chrome
(deleted), video/webm
Details 
These two canvas applications use a javascript Drag'n drop mechanism:

http://apirocks.com/html5/src/canvasphoto/index.html
http://github.com/mojombo/ernie/network

I guess they redraw the canvas on the "mousemove" events.

It's really smooth on Windows and Mac, and really slow on Linux (almost no redraw during the drag). It's smooth on Chrome 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.
Depends on: 702158
Attached video screencast: no skia vs. skia vs. chrome (deleted) — 
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.
Depends on: 723110
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 2.6.37.6-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 2.6.37.6-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.
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  ?
Depends on: 740200
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.
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 18 votes.
:lsalzman, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(lsalzman)
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(lsalzman)
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: