Forgot to add the numbers:

This is running on a 13in MacBook Pro 2016.

Chrome 58:
Max frame time 47.85000000000002
Min frame time 18.464999999999918
Avg frame time 21.610949999999892

Safari 10.1
Max frame time 7.899999999999636
Min frame time 1.2999999999992724
Avg frame time 2.721800000000023

Firefox 53
Max frame time 11.470000000000027
Min frame time 3.115000000000009
Avg frame time 5.665640000000006

Able to reproduce the issue on windows 7 , Ubuntu 14.04 and Mac 10.12.4 using chrome version 58.0.3029.110 and canary 60.0.3106.0.
Observed the Avg frame time is 15 to 18 on windows& Linux 
But seeing 20 to 25 on Mac.
This issue is observed till M55. M54 and for M54 and prior versions the animation is not working.
Marking it as Untriaged to get more inputs from dev team.

Thanks,

When the canvas is GPU-accelerated, I am seeing a lot of CPU time spent in the renderer main thread, and a lot of texImage2D calls, which tells me that ganesh is probably rendering the shadow blurs on the CPU then uploading to the GPU.

This could use an accelerated code path.

Assigning to bsalomon for further triage.

Passing the buck to the Skia gpu wrangler du jour, egdaniel@

Ahem... he's a person, not a status.  LOL.

I was wondering why autocomplete wasn't working!

So I'm trying to capture an SKP to investigate this, but I'm failing to be able to record the canvas2d draw commands. Anyone know how to get the canvas2d draws into an skp through chrome?

There is no instrumentation for that because canvas content are not "painted" via blink regular paint phase.  The GPU-accelerated implementation for 2D canvas does use SkPictures internally, but depending on the use case there can be multiple recordings/playbacks per animation frame.  The SkPicture playback happens in Canvas2DLayerBridge::FlushRecordingOnly.  That might be a good place to hack your local build to make it spit out an skp.

So after some initial investigation, the issue is that from canvas we are drawing an arc with a sweep angle of 360. Skia does not current support drawing a sweep angle of >= 360, so in Path:AddEllipse, it breaks up the draw into two arcTo calls in skia 0-180 and 180-360. At this point Skia is not able to detect that the path it is drawing is a circle, so in the gpu backend we end up going down slow path drawing instead of fast circle draws/blurs.

+caryclark@

shadows in html canvas set SkBlurMaskFilter::kIgnoreTransform_BlurFlag; this causes Skia to give up on the GPU path and use the slower raster path.

Changing ShadowAndForegroundDrawLooper() to kShadowRespectsTransforms and adding smarts to make the arc an oval draws correctly and draws as quickly as Safari.

Next: why does canvas2d set kShadowIgnoresTransforms, and why does that cause Skia to give up on the GPU optimization.

Re: #11: canvas sets that flag because that's canvas spec behaviour: shadow offset and radius are unaffected by CTM. I don't know why it's kicking us off the GPU path, though.

The following revision refers to this bug:
  https://skia.googlesource.com/skia/+/aa28bfcc5aff5bac0a30c671db9301896d6849fe

commit aa28bfcc5aff5bac0a30c671db9301896d6849fe
Author: Greg Daniel <egdaniel@google.com>
Date: Wed May 31 02:06:36 2017

Allow GPU blur fast path for circles and rects when using ignore xform

Since the only thing it looks like we alter when using the ignore
xform flag is the blur radius, this is already handled by the
computeXformedSigma function call. Thus it should be safe to just use
the current fps and draws for circle and rect.

Bug: chromium:724735
Change-Id: I7a2f52dc965dcd875b8c2802141f30607a966347
Reviewed-on: https://skia-review.googlesource.com/18122
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>

[modify] https://crrev.com/aa28bfcc5aff5bac0a30c671db9301896d6849fe/src/effects/SkBlurMaskFilter.cpp

Is this work done?