Open Bug 1105337 Opened 8 years ago Updated 3 years ago

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


(Core :: Canvas: 2D, defect)

Not set




(Reporter: jandem, Unassigned)


(Blocks 1 open bug)



(1 file)

Attached file 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: = true = skia

I get 35806 and the animation is way faster. Still slower than Chrome and Safari though...
We should also try this on Windows, of course. I can do that later today.
Jeff, who's the right person to look at this?
Flags: needinfo?(jmuizelaar)
On linux Nightly 3491, Chromium 14638
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.
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.
Flags: needinfo?(jmuizelaar)
How much we care is a policy question about BrowserMark, right?  My understanding is that we care.
I'll find out exactly what that means, taking the non-technical part of the discussion off line.
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
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.
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)
You need to log in before you can comment on or make changes to this bug.