Looks like we are swamped in the commit. Possibly we are not clipping properly?

Deleted: trace_trace.json 4.1 MB

trace_trace.json 4.1 MB View Download

The timing results are consistent with re-rastering or otherwise doing per-pixel work on the Pixel, but not on any other platforms. Is there something special about the Pixel GPU?

Raster is slow on this example because it triggers the ganesh veto, due
to complex path rendering. There is a plan to be able to get rid of this
veto in about a quarter, with a new algorithm by senorblanco@.


You can test by forcing on GPU raster for all layers in about:flags.

I've added the results for the same device with GPU forced. Much better, but still slower than Firefox on the same device.

Also, the second demo on http://output.jsbin.com/xeveval/quiet, which is scaling within an overflow:auto container is significantly slower. I guess we can't clip as much here?

I added this feature to Canary and all my GIFS in Twitter look like the attached

Deleted: Capture.PNG 270 KB

	Capture.PNG 270 KB View Download

ping for senorblanco - can we make progress here?

The Ganesh veto-to-software is gone as of M60. I do have some plans to improve non-MSAA performance, but I don't have further work planned for the MSAA path (which is likely what Pixel is using here). I suspect we're blocked on something other than path rasterization, although a trace would be helpful.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Assigning this to senorblanco to triage/investigate/WontFix.