1105337 - Browsermark "Graphics Canvas" test much slower than Chrome and Safari

Status: NEW

(Core :: Graphics: Canvas2D, defect)

Description

[Jan de Mooij [:jandem]]

Attachment: Standalone testcase

See the attachment. It runs for 15 seconds, then shows the score. I get the following numbers on OS X:

Nightly:    8070
Safari 8:  40346
Chrome 41: 68185

The animation is also way slower in Firefox

According to Instruments, > 60% of the time is under DrawTargetCG::Stroke.

I see ~25% in argb32_shade_axial_RGB (the test does use createRadialGradient) and 19% in aa_render.

If I set:

  gfx.canvas.azure.accelerated = true
  gfx.canvas.azure.backends = skia

I get 35806 and the animation is way faster. Still slower than Chrome and Safari though...

Comment 1

[Jan de Mooij [:jandem]]

We should also try this on Windows, of course. I can do that later today.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Jeff, who's the right person to look at this?

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

On linux Nightly 3491, Chromium 14638

Comment 4

[Jeff Muizelaar [:jrmuizel]]

So the way this test case draws is sort of dumb iirc. At sometime I think I rewrote a faster version of it. So I'm not in a rush to try to optimize the drawing it does. 

It also uses setTimeout(1) instead of requestAnimationFrame(). If you switch it to requestAnimationFrame from setTimeout(1) our performance with accelerated skia canvas on OS X is comparable to Chrome. I don't think we have any interest in fixing this on our side either. We should try to reach out to the browsermark people to fix there stuff or if that doesn't work publicly discredit the benchmark.

Comment 5

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

Martin Best is the right person to look at this first.  I don't doubt the numbers, but I don't know how much to care.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Attachment: Speed up drawing code by replacing gradient with an image

Here's the change that I made.

Comment 7

[Boris Zbarsky [:bzbarsky]]

How much we care is a policy question about BrowserMark, right?  My understanding is that we care.

Comment 8

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

I'll find out exactly what that means, taking the non-technical part of the discussion off line.

Comment 9

[Guilherme Lima]

On Windows I got
IE 11 - 7400
Chrome 39 - 18400
Nightly (D2D1.1/D3D11/OMTC) - 4100

about:memory shows
1,368.52 MB ── gpu-committed
    0.00 MB ── gpu-dedicated
1,386.21 MB ── gpu-shared
  144.08 MB ── heap-allocated
        218 ── heap-chunks
    1.00 MB ── heap-chunksize
  148.32 MB ── heap-committed
  218.00 MB ── heap-mapped
      2.94% ── heap-overhead-ratio
    0.00 MB ── imagelib-surface-cache
    1.06 MB ── js-main-runtime-temporary-peak
          0 ── low-commit-space-events
1,717.85 MB ── private
1,728.84 MB ── resident
2,203.00 MB ── vsize
1,470.13 MB ── vsize-max-contiguous

and 223.48 MB (100.0%) -- explicit

Comment 10

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

For this particular part of the browsermark (vectors), turning off acceleration is the way to go - we know D2D is really bad there.  With acceleration off, we are  faster than Chrome (~50%) and Edge (~20%) on my Windows 10. 8x faster than accelerated Firefox.

However, on the bitmaps part of the browsermark test (the first test, the one extracted here is the fifth), we are faster (4x) with acceleration enabled.

Overall, browsermark is 10% better with acceleration.

We could consider trying to detect what the content is and switching.

Comment 11

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

Sorry, when talking about different parts and performance differences for the "first test" and "fifth test" - those are canvasmark, rather than browsermark references.  Same conclusion though - there are canvas operations that are much faster with our software backends, and some that are much faster with our accelerated backend(s)