All benchmarks are under pr.gg/animometer/developer.html
- Set "Ramp" mode for benchmarking.
- Set "Keep at a fixed complexity" for profiling. Set an appropriate [high] complexity next to each test's name.
File any performance bugs found as blocking this issue.
On my MBP, w/ Ganesh, on a low DPI monitor:
Chromium 52 28c0dd4fc82d8834c0508492fc693204da39e21b
Ramp Score = 220
Safari 9.1 (11601.5.17.1)
Ramp Score = 920
So Safari is ~4x faster.
I see my trace didn't get attached, woops. I'll attach that tonight.
junov@ What's going on here with rendering in canvas? Both software and ganesh are much slower than Safari.
On every requestAnimationFrame this benchmark is doing:
1) Clear the canvas
// Clear the canvas
context.clearRect(0, 0, this.size.x, this.size.y);
2) Loop through a set of Shape objects calling draw(). The benchmarks use a predictable pseudo random generator to pick the set. Any given complexity will have the same set of shapes.
The draw commands for the 4 different shape types in this benchmark are:
// CanvasArcSegmentFill:
context.fillStyle = this._color;
context.beginPath();
context.arc(this._point.x, this._point.y, this._radius, this._startAngle, this._endAngle, this._counterclockwise);
context.fill();
// CanvasEllipseFill:
context.fillStyle = this._color;
context.beginPath();
context.ellipse(this._center.x, this._center.y, this._radius.width, this._radius.height, this._rotation, this._startAngle, this._endAngle, this._anticlockwise);
context.fill();
// CanvasRectFill:
context.fillStyle = this._color;
context.beginPath();
context.rect(this._point.x, this._point.y, this._width, this._height);
context.fill();
// CanvasArcToSegmentFill:
context.fillStyle = this._color;
context.beginPath();
context.moveTo(this._point1.x, this._point1.y);
context.arcTo(this._point2.x, this._point2.y, this._point3.x, this._point3.y, this._radius);
context.fill();
As you might suspect, much of this is bound on path rendering, which in Canvas does not use MSAA currently, so doesn't use the tessellating path renderer.
You can experiment with MSAA for canvas with --canvas-msaa-sample-count=X. Try 4 for hidpi, 8 for lodpi, which is what we're using currently in GPU rasterization. On my Retina MBP (discrete GPU), this takes results from ~220 to ~550.
This may be a viable solution for GPUs with decent MSAA (i.e., non-Intel). However, we have to decide if we want to trade the extra VRAM required for MSAA for improved performance.
I also have a screenspace-AA version of the tessellating path renderer, which doesn't require MSAA. It's still a WIP, but gives a 20-40% boost. Not as dramatic as the above, but works on Intel and doesn't cost extra VRAM.
I'm not seeing 4X faster. On Intel, with "maintain target FPS", I see a score of 506 on Safari, and 251 on today's Chrome Canary. (Note that these are different score ranges than above -- Justin pointed out that the "maintain target FPS" option yields much more consistent results than "Ramp".)
I just noticed that with --force-display-list-2d-canvas, the GPU veto was not noticing the paths in this test (or other canvas tests). This is because the canvas commands are inside an SkPictureImageFilter which the GPU veto does not see.
I wrote up a quick Skia patch here which fixes it: https://codereview.chromium.org/2036783005/.
It now vetos to MSAA, but strangely, the performance is worse than with --canvas-msaa-sample-count set.
Comment 1 by dk...@chromium.org
, Apr 27 2016Status: Assigned (was: Untriaged)