Open Bug 1105337 Opened 8 years ago Updated 3 years ago
Browsermark "Graphics Canvas" test much slower than Chrome and Safari
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...
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?
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.
Here's the change that I made.
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.