It looks like we're doing all the rasterization on the Main Thread.  We could possibly see an improvement with display-list-canvas drawing on the Impl side.  --force-display-list-2d-canvas isn't making a difference.

Deleted: trace_animometer-canvas-arcs.json.gz 769 KB

trace_animometer-canvas-arcs.json.gz 769 KB Download

Even with the deferred rendering of the GPU-accelerated path, I am seeing most of the run-time being spent in V8 execution.  It looks like draw call overhead (including SkPicture recording) may be the main bottleneck for many of the canvas sub-benchmarks. I did not expect this. I was expecting more cases to be GPU bound or CPU bound in skia.  Must figure out what's up with that.

It appears that the arc paths use a fallback code path that renders the path on the CPU then uploads each individual path as a texture.  This CPU to GPU overhead is what is killing performance.  There are two obvious solutions:
1. Improve the GPU path rasterizer so that it can handle this case. (bsalomon?)
2. Make the canvas fallback to software rasterization when this use case is detected. I found that turning disabling accelerated 2D canvas more than triples the performance of this benchmark.

In the short term, I think 2. is the most realistic.
@bsalomon: Can you give some guidance on which cases of path rendering rusult in SW draw -> tex upload.  Is there an easy way to query this?

Are the paths just partial circular arcs?

Yeah, stroked

Ahh, so IIUC from #2 we're not usually Skia playback/GPU bound, but from #3 on the Canvas arcs test we are?

@#6: Correct.

what type of caps? We can probably add a fast path for this.

Is there any hope of auto-selecting MSAA for canvas like we do for raster?

So i tried running with --canvas-msaa-sample-count=4.  The rendering all happens on the GPU when I do that (Yay!), but I only saw a 10% boost in performance (Boo). Rendering becomes completely GPU-bound. It is still way faster to render on the CPU.

This is on a stock z620 Windows machine.

 Issue 606679  has been merged into this issue.

junov: is the draw call overhead similar to what I mentioned in issue 606685?

@#11: No this one is substantially different. It's a case where GPU is slower than CPU rendering.

Do we know why GPU is slower than CPU in this case, or are we still looking into that?

It is because we have no rendering algorithm for drawing anti-aliased concave paths on the GPU.  So the GPU code path ends up creating a temporary software canvas for drawing the arc, uploads the result to a GPU texture, and composites it onto the GPU canvas.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6edcd8c85219d193f7f6ada459635a3a295bd72f

commit 6edcd8c85219d193f7f6ada459635a3a295bd72f
Author: sebastienlc <sebastienlc@google.com>
Date: Tue May 24 00:43:23 2016

Test page for rendering throughput for canvas arcs

BUG=606678

Review-Url: https://codereview.chromium.org/1995163002
Cr-Commit-Position: refs/heads/master@{#395488}

[modify] https://crrev.com/6edcd8c85219d193f7f6ada459635a3a295bd72f/tools/perf/page_sets/tough_canvas_cases.py
[add] https://crrev.com/6edcd8c85219d193f7f6ada459635a3a295bd72f/tools/perf/page_sets/tough_canvas_cases/rendering_throughput/bench.js
[add] https://crrev.com/6edcd8c85219d193f7f6ada459635a3a295bd72f/tools/perf/page_sets/tough_canvas_cases/rendering_throughput/canvas_arcs.html
[add] https://crrev.com/6edcd8c85219d193f7f6ada459635a3a295bd72f/tools/perf/page_sets/tough_canvas_cases/rendering_throughput/canvas_arcs.js

This owner is not able to receive e-mails, please re-triage.

senorblanco@, does your recent change for tesselating path renderer fix this case? Is it even fixable?

Sadly, no. The tessellator is a wash vs. the default path renderer on this test case.

I have some ideas about how to speed it up, but nothing guaranteed.