568526 - Canvas fill and stroke are extremely slow on Linux

Status: NEW

(Core :: Graphics: Canvas2D, defect)

Description

[Bug Filler]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: Gecko/20100401 Firefox/3.6.3

The canvas stroke and fill are very slow. Especially when fill/stroke circle or rectangle, the rendering area should be able to calculated easily.

The attached html file shows the problem.


Reproducible: Always

Comment 1

[Bug Filler]

Attachment: demo the problem.

Comment 2

[Boris Zbarsky [:bzbarsky]]

How slow is slow?  Over here I see fill take about 72ms and stroke take about 330ms with the "circle" testcase attached (so about 10-15% faster than Chrome, say).  But that's on Mac.  On Linux, the business about having to talk to the X server might affect the numbers, obviously....

Comment 3

[Bug Filler]

Attachment: demo the problem

add a button to show/hide the canvas.

Hiding the canvas does not change the timing much.

On Linux, one obvious thing is that fill circle is about the same speed of stroke circle (400/490 ms). However, fill rectangle is 1/10 of stroke rectangle(30/470 ms). Therefore the fill circle on Linux is not as efficient as on Mac.

Stroke 2500 circle in 500ms is interactive applications at 30 FPS: (1000/30)*(2500/500)~= 170 circles (radius=4, lineWidth=2) allowed. And it seems the number is linear against the radius.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Hiding the canvas isn't relevant; what's relevant is that on Linux the canvas backing store is on the X server (which we're considering changing).

As far as that goes, I wonder whether we're asking the X server to do the fill on Linux (and ending up in slow Render code or something).

I assume your 400/490 number doesn't depend on whether you click the circle or rectangle button first?

Comment 5

[Bug Filler]

400 was for filling and 490 was for stroking of circles. Filling was just a little bit faster than stroking. Your numbers were 72 for filling and 330 for stroking, a much bigger difference. That's why I said on Linux, the filling was slower than on Mac, relatively.

I tested a few time by randomly clicking on the buttons. There were about less than 5% variation on the same test. Order did not matter much.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> 400 was for filling and 490 was for stroking of circles. 

Yes, I understand that.

> Order did not matter much.

OK.  So it's not the fact that we have to talk to the X server per se, then.  Sounds like it's the usual "Render is really slow" issue...

roc, do you happen to know whether we have a bug to switch to an image surface for canvas on Linux already?  We keep talking about it....

Comment 7

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: add env var

not sure where the bug is, but let's do this.  This way we can do some analysis with an easy way to switch back and forth.

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: add env var, really

Whoops, did a qnew in the wrong source tree.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 448170 [details] [diff] [review]
add env var, really

r=bzbarsky

Comment 10

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Ok, that patch was checked in -- can rerun the test with MOZ_CANVAS_IMAGE_SURFACE=1 env var and compare to see what perf wins (if any) we'd get on linux by switching to image surfaces.  I also wonder if that's system dependant and how we could decide what a reasonable default could be...

Comment 11

[Boris Zbarsky [:bzbarsky]]

Using attachment 447932 [details], for the circle case I get "65ms" for fill and "789ms" for stroke on Linux without that env var set, and "132ms" for fill and "854ms" for stroke with it not set.  Note that this is using a remote X server.

Which doesn't exactly match comment 4 on the one hand, and seems to indicate that in this case an image surface is not a win on the other...

That said, the numbers without env var set on attachment 447780 [details] are the same as those _with_ the env var set on attachment 447932 [details], and does not seem to depend on the env var at all.

For comparison, over here the rect numbers are about 2ms fill and 8ms stroke on Linux (no matter what the env var is set to).  That doesn't really match comment 3 either....

Comment 12

[Boris Zbarsky [:bzbarsky]]

Er, ignore the env var stuff in comment 11.  I was using a build without that test patch, apparently.  Though again, to be clear, that was a Linux client and a Mac X server.

I just retested with both client and server on the F12 box, and I get numbers like so:

Circle without env var: 50ms fill, 446ms stroke
Rect without env var: 1ms fill, 5ms stroke

(so about 2x faster than the remote X numbers, and nothing like the ratios reporter is seeing).

Building with the env var patch now.

Comment 13

[Boris Zbarsky [:bzbarsky]]

With MOZ_CANVAS_IMAGE_SURFACE=1 and a local X server I get:

Circle: 22ms fill, 175ms stroke
Rect: 1ms fill, 5ms stroke

The remote X server numbers are basically identical (as expected; we're no longer involving the X server here).

Comment 14

[Bug Filler]

With MOZ_CANVAS_IMAGE_SURFACE=1 (Gecko/20100601) I saw a big improvement on circle fill with 5~20% slow down on circle fill. And huge improvement on rectangle fill and stroke.

However, without the MOZ_CANVAS_IMAGE_SURFACE=1, circle stroke dropped a lot with a good improvement on cirle fill. 

Here is the number:

Firefox 3.6.3, baseline
  circle =>   Draw 32 ms, Fill: 411 ms, Stroke: 504 ms
  fillRect => Draw 52 ms, Fill: 0 ms,   Stroke: 1 ms
  Rect =>     Draw 20 ms, Fill: 29 ms,  Stroke: 458 ms

Gecko/20100601 without MOZ_CANVAS_IMAGE_SURFACE
  circle =>   Draw 22 ms, Fill: 244 ms, Stroke: 1709 ms
  fillRect => Draw 19 ms, Fill: 1 ms,   Stroke: 0 ms
  Rect =>     Draw 4 ms,  Fill: 6 ms,   Stroke: 22 ms

Gecko/20100601 with MOZ_CANVAS_IMAGE_SURFACE=1
  circle =>   Draw 22 ms, Fill: 75 ms, Stroke: 529 ms
  fillRect => Draw 21 ms, Fill: 0 ms,  Stroke: 0 ms
  Rect =>     Draw 4 ms,  Fill: 4 ms,  Stroke: 22 ms

As can be seen, firefox 3.6.3 -> Gecko/20100601 -> MOZ_CANVAS_IMAGE_SURFACE=1
    circle stroke is 504->1709->529 (sometime up to 600).
    circle fill is   411->244->75
    rect stroke is   458->22->22
    rect fill is     29->6->4

Comment 15

[WL]

Anyone still working on this issue?
Maybe this bug applies to all platform as the same thing happens even with the Direct2D HW acceleration on.
This is the test case.
http://glimr.rubyforge.org/cake/canvas.html#Polaroids

Comment 16

[Boris Zbarsky [:bzbarsky]]

> Maybe this bug applies to all platform as the same thing happens even with the
> Direct2D

_This_ bug is very much Linux-specific.  There may be some other bug affecting Direct2D; it should be filed separately.

Comment 17

[hannes.janetzek]

circle test: Firefox 22.0 (default ubuntu 13.04)
Draw 16 ms
Fill: 141 ms
Stroke: 959 ms

circle text: Chromium Version 28.0.1500.71 (same pc)
Draw 2 ms
Fill: 13 ms
Stroke: 86 ms

Anyone? is rendering still done via Cairo/XRender?