1001954 - low canvas lineTo performance

Status: RESOLVED WORKSFORME

(Core :: Graphics: Canvas2D, defect)

Description

[pinggi]

Attachment: firefoxLineDrawingPerformanceTest.html

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140314220517

Steps to reproduce:

Firefox 28 32-bit is slow with a visible lag when using the new Google Maps (http://maps.google.com) and terribly slow (~2 fps) when I display demo page (http://www.madore.org/~david/.tmp/e8nowebgl.html) on win 7 64-bit.

I've investigated that a little bit and have found the following.




Actual results:

Google maps (canvas+webgl):

hwacc off + webgl on => very slow, movement causing blurry text and sharp lines
hwacc on + webgl on => slow, movement causing blurry text and sharp lines
hwacc off + webgl off => normal
hwacc on + webgl off => quick

Demo page (canvas, lineTo):

hwacc on + webgl on => 2 fps
hwacc on + webgl off => 2 fps
hwacc off + webgl on => 10 fps (rendering with skia)
hwacc off + webgl off => 10 fps (rendering with skia)


I made my own test. Created random lines animation with requestAnimationFrame (enclosed).

ff hwacc on:	 							 2 ms / 300 ms
ff hwacc off:								71 ms / 110 ms (skia)
ff hwacc on + gfx.direct2d.disabled = true:			71 ms /  83 ms
chrome hwacc on:		 					 1 ms /  25 ms (skia)


Measured on AMD Athlon II X4

about:support:
Adapter Description: ATI Radeon HD 4290
Adapter Drivers: aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64
Adapter RAM: 192
Driver Version: 8.970.100.1100
GPU Accelerated Windows: 1/1 Direct3D 9

All plugins and extensions disabled with new profile.



Expected results:

I expected webgl using directx or opengl to be super quick with hw acceleration on but it isn't.

I expected that gpu accelerated line drawing is faster than cpu in total. But the one frame takes 300 ms which includes 1000 lines drawing in 2 ms. What the Firefox does in remaining 298 ms?

If I turn off the hw acceleration, it uses skia library for drawing. Then the frame takes 110 ms including 71 ms for 1000 lines done by cpu. So 39 ms for another work by firefox.

I found interesting improvement when hwacc is on but direct2d is disabled. Then frame drops to 83 ms only. It is the best Firefox can do - 12 fps while Chrome using the skia library simply gets to 25 ms including 1ms for drawing 1000 lines on the same computer.

My current settings is currently this:

hardware acceleration: checked
webgl.disabled = true
gfx.direct2d.disabled = true

The Google maps app is fast, the demo page is displayed in 12 fps. It's not bad, but also not good. if I browse a web page that need webgl support, I must go to about:config, change webgl.disabled to false and then restart Firefox.

Well, question is why there is some kind of regression in firefox using direct2d. Why the frame takes 300 ms (causing 3 fps) instead of 16 ms (60 fps)? The line drawing takes only 2 ms.

I'd like to have Firefox fast as Chrome on my pc. What can I do?

Comment 1

[:Gijs (he/him)]

The first thing to check would be if current nightlies (see http://nightly.mozilla.org/ ) have the same performance characteristics. :-)

Comment 2

[pinggi]

Yes, it has. I've installed file named 'firefox-31.0a1.en-US.win32.installer.exe' on my second computer with NVIDIA Quadro NVS 135M.

Here is the result:

gfx.direct2d.disabled = false (in about:config):
  Google map: slow, movement causing blurry text and sharp lines
  E8 demo: 2 fps
  1000 lines (my test): 1 ms [drawing] / 228 ms [frame]

gfx.direct2d.disabled = true (in about:config):
  Google map: faster
  E8 demo: 10 fps
  1000 lines (my test): 41 ms [drawing] / 53 ms [frame]

When direct2d is enabled 1 frame takes 228 ms including 1 ms drawing itself.
When direct2d is disabled 1 frame takes 53 ms including 41 ms drawing itself.

So why the frame takes too much time in case of gpu drawing? There is something wrong.

Comment 3

[:Gijs (he/him)]

Bas, can you help here?

Comment 4

[Bas Schouten (:bas.schouten)]

(In reply to :Gijs Kruitbosch from comment #3)
> Bas, can you help here?

It should be noted Direct2D is not particularly great at drawing fine lines, but I would expect better performance than this, just for reference, how does IE11 do?

Comment 5

[Bas Schouten (:bas.schouten)]

Hrm, I've confirmed IE11 is a lot faster myself actually, somebody should get a profile so we can see where we're spending time.

Comment 6

[Bas Schouten (:bas.schouten)]

Attachment: e8nowebgl-mod.html

I've modified the E8 demo page a tiny bit to be less silly. This way it's a -lot- faster on Firefox, but it's -slower- on IE11 (although both perform quite well). The difference between the original and my modded version is that in the original it did a MoveTo, LineTo and Stroke for each edge, in my modified version it did a MoveTo, LineTo for each edge and then one stroke.

Now I suspect the reason that becomes slower on IE because I bet IE actually does a D2D StrokeLine for a MoveTo, LineTo, Stroke series of commands. Where-as we build a whole path object for each Stroke, even if all the path contains is one line.

We could do the same optimization IE11 does, it's not that hard.

Comment 7

[Bas Schouten (:bas.schouten)]

Asking Milan to prioritize this. This might actually be importance since Google Maps is fairly common and I've heard more people complain about the performance, but I'll leave that up to the stakeholders. I'm not actually 100% certain we'll improve google maps a lot. I'd expect this optimization to be about 4-8 hours of work for someone who knows that they're doing. So based on that we can see what we're going to do about it.

Fwiw, this will -not- improve the performance of the bugreporter's original testcase attached to the bug, I couldn't reproduce any slowness in there.

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

I'm not sure I understand what is being improved - not the original testcase, and not sure it'll improve Google Maps a lot, but perhaps still somewhat?  What is being improved?  A couple of days doesn't sound like a big deal, so I'm sure we can fit it somewhere into 31, but I just wanted to clear up as to what we're attempting to improve.

Comment 9

[Bas Schouten (:bas.schouten)]

We would be improving the performance of drawing individual lines significantly. How much Google Maps does that - I don't know. This test case in particular: http://www.madore.org/~david/.tmp/e8nowebgl.html would improve a -lot-.

Comment 10

[pinggi]

Bas, how can a stroke drawing in one cycle be faster than only one drawing per several cycles?

I've done tests of the modified version. 
Laptop: Intel Core2 Duo, 2.4 GHz, NVIDIA Quadro NVS 135M
Here are the results:

Original:
http://www.madore.org/~david/.tmp/e8nowebgl.html
Firefox 29		48% of CPU: 30 frames in 12 seconds => ~ 2.50 fps (frames counted visually by me)
IE 10    		37% of CPU:  ? frames in  ? seconds => ~ 25 fps (rough estimate, animation is smooth)
Chromium 36		88% of CPU:  ? frames in  ? seconds => ~ 20 fps (rough estimate, animation is quite smooth)

Modified:
https://bugzilla.mozilla.org/attachment.cgi?id=8414874
Firefox 29		54% of CPU: 30 frames in 24 seconds => ~ 1.25 fps (frames counted visually by me)
IE 10			55% of CPU: 30 frames in 25 seconds => ~ 1.2 fps (frames counted visually by me)
Chromium 36		31% of CPU:  ? frames in  ? seconds => ~ 30 fps (rough estimate, animation is smooth)

My lines test:
https://bug1001954.bugzilla.mozilla.org/attachment.cgi?id=8413305
Firefox 29		54% of CPU: 224 ms per frame, 1-2ms drawing => ~ 4.4 fps
IE 10			55% of CPU: 239 ms per frame, 1-2ms drawing => ~ 4.1 fps
Chromium 36		21% of CPU:  21 ms per frame,   1ms drawing => ~ 47.6 fps

No surprise. Stroke in every cycle is slower than the stroke called only once. Chromium is super fast in comparing to Firefox.

Comment 11

[pinggi]

I take the last sentence back. Sorry.

The sentence "No surprise. Stroke in every cycle is slower than the stroke called only once." is not correct. I've realized that you actually modify the e8 demo to draw strokes only once.
Firefox 29 and IE 10 are actually slower in drawing several strokes in once.

Only the Chromium behaves as the browser should behave with hardware acceleration.
Firefox draws lines in 1-2 ms but the whole one frame takes 224 ms. Doesn't it mean that the access of real device is the problem?

Comment 12

[pinggi]

Attachment: firefoxLineDrawingPerformanceTest_modifiedStrokeInOneCycle.html

modified firefoxLineDrawingPerformanceTest.html to draw strokes in every cycle

Comment 13

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Bas Schouten (:bas.schouten) from comment #9)
> We would be improving the performance of drawing individual lines
> significantly. How much Google Maps does that - I don't know. This test case
> in particular: http://www.madore.org/~david/.tmp/e8nowebgl.html would
> improve a -lot-.

I like that - perhaps it's a different bug (?), but either way, it's something that's worth doing when you have time.

On the topic directly in this bug - just stating the obvious, though perhaps not relevant - Chromium is using OpenGL and IE and Firefox are using DirectX.

Comment 14

[pinggi]

I'm adding modified version of my lines test. There is beginPath, moveTo, lineTo and stroke performed within every cycle.

https://bug1001954.bugzilla.mozilla.org/attachment.cgi?id=8416742
Firefox 29 hw=off, dis=true               54% of CPU: 237 ms per frame, ~135 ms drawing => ~ 4 fps
Firefox 29 hw=off, dis=false              54% of CPU: 237 ms per frame, ~135 ms drawing => ~ 4 fps
Firefox 29 hw=on, dis=false               54% of CPU: 166 ms per frame, ~135 ms drawing => ~ 6 fps
Firefox 29 hw=on, dis=true                54% of CPU: 166 ms per frame, ~135 ms drawing => ~ 6 fps
Firefox 29 hw=on, dis=false,be=skia       54% of CPU: 166 ms per frame, ~135 ms drawing => ~ 6 fps
Firefox 29 hw=on, dis=false,be=cairo      54% of CPU: 208 ms per frame, ~135 ms drawing => ~ 4.8 fps
Firefox 29 hw=on, dis=false,be=direct2d   54% of CPU: 166 ms per frame, ~135 ms drawing => ~ 6 fps
Firefox 29 hw=on, dis=true,be=skia        55% of CPU: 161 ms per frame, ~135 ms drawing => ~ 6.2 fps
Firefox 29 hw=on, dis=true,be=cairo       54% of CPU: 186 ms per frame, ~135 ms drawing => ~ 5.3 fps
Firefox 29 hw=on, dis=true,be=direct2d    54% of CPU: 161 ms per frame, ~135 ms drawing => ~ 6.2 fps
Firefox 29 hw=off, dis=false,be=skia      53% of CPU: 240 ms per frame, ~135 ms drawing => ~ 4.1 fps
Firefox 29 hw=off, dis=false,be=cairo     54% of CPU:   ? ms per frame,    ? ms drawing => ~ 0 fps
Firefox 29 hw=off, dis=false,be=direct2d  54% of CPU: 238 ms per frame, ~135 ms drawing => ~ 4.2 fps
Firefox 29 hw=off, dis=true,be=skia       54% of CPU: 208 ms per frame, ~135 ms drawing => ~ 4.8 fps
Firefox 29 hw=off, dis=true,be=cairo      54% of CPU:   ? ms per frame, ~135 ms drawing => ~ 5.3 fps
Firefox 29 hw=off, dis=true,be=direct2d   54% of CPU: 239 ms per frame, ~135 ms drawing => ~ 4.1 fps
IE 10                                     55% of CPU:  16 ms per frame,  3-4 ms drawing => ~ 60 fps
Chromium 36                               21% of CPU:  18 ms per frame,    2 ms drawing => ~ 55 fps

hw => allow hardware acceleration
dis => gfx.direct2d.disabled
be => gfx.canvas.azure.backends


IE 10 is the fastest in this case. Firefox still increadibly slow :-(

Comment 15

[pinggi]

The same for drawing outside cycle:

https://bug1001954.bugzilla.mozilla.org/attachment.cgi?id=8413305
Firefox 29 hw=on, dis=false,be=skia       54% of CPU: 226 ms per frame, ~1-2 ms drawing => ~ 4.4 fps
Firefox 29 hw=on, dis=false,be=cairo      50% of CPU: 289 ms per frame, ~1-2 ms drawing => ~ 3.4 fps
Firefox 29 hw=on, dis=false,be=direct2d   54% of CPU: 225 ms per frame, ~1-2 ms drawing => ~ 4.4 fps
Firefox 29 hw=on, dis=true,be=skia        55% of CPU: 226 ms per frame, ~1-2 ms drawing => ~ 4.4 fps
Firefox 29 hw=on, dis=true,be=cairo       50% of CPU: 278 ms per frame, ~1-2 ms drawing => ~ 3.5 fps
Firefox 29 hw=on, dis=true,be=direct2d    54% of CPU: 226 ms per frame,   ~1 ms drawing => ~ 4.4 fps
Firefox 29 hw=off, dis=false,be=skia      50% of CPU: 286 ms per frame, ~1-2 ms drawing => ~ 3.4 fps
Firefox 29 hw=off, dis=false,be=cairo     54% of CPU:   ? ms per frame,    ? ms drawing => ~ 0 fps
Firefox 29 hw=off, dis=false,be=direct2d  50% of CPU: 319 ms per frame, ~1-2 ms drawing => ~ 3.1 fps
Firefox 29 hw=off, dis=true,be=skia       50% of CPU: 318 ms per frame, ~1-2 ms drawing => ~ 3.1 fps
Firefox 29 hw=off, dis=true,be=cairo      54% of CPU:   ? ms per frame,    ? ms drawing => ~ 0 fps
Firefox 29 hw=off, dis=true,be=direct2d   50% of CPU: 317 ms per frame, ~1-2 ms drawing => ~ 3.1 fps

IE 10                                     54% of CPU: 232 ms per frame,    2 ms drawing => ~ 4.3 fps
Chromium 36                               23% of CPU:  18 ms per frame,  0-1 ms drawing => ~ 55 fps

Comment 16

[pinggi]

My lines drawing test overview:

outside cycle:
   Firefox 29         ~ 3-4 fps (1-2 ms / 225-319 ms)
   IE 10              ~   4 fps (2 ms / 232 ms)
   Chromium 36        ~  55 fps (1 ms / 18 ms)

inside cycle:
   Firefox 29         ~ 4-6 fps (135 ms / 161-240 ms)
   IE 10              ~  60 fps (3-4 ms / 16 ms)
   Chromium 36        ~  55 fps (2 ms / 18 ms)


When Firefox is set to (hwacc=off, d2ddisable=false, backends=cairo), there is something wrong - animation is stopped after the first draw => 0 fps!

You can see here that there is something wrong with Firefox. It is really slow.


1. If backend is set to cairo, hw acc is unchecked and d2d is enabled, Firefox draws the first frame only (while CPU is still under the load)
2. Firefox is more than 10 times slower if drawing is performed inside cycle

Comment 17

[pinggi]

3. strange is that drawing lines takes 2 ms, but frames takes 300 ms. Does it mean that gpu needs 300 ms for drawing lines while javascript engine needs only 2 ms ? :-O

Comment 18

[pinggi]

Any news on that?

Why Firefox is slower even if hardware acceleration is used?

I've switched to Chrome for some time...

Comment 19

[Mayank Bansal]

all the three testcases perform the same on Nightly and Chrome.