It happens because of GPU rasterization which was enabled in some versions of Chrome, for example initial bisecting reveals r418346 (55.0.2860.0) "Enable GPU rasterization for windows waterfall".

In other words, Chrome 48 is also affected. Thus, to reproduce reliably and find the underlying cause, I had to force-enable chrome://flags/#enable-gpu-rasterization or use a command line switch:

Bisect using --enable-gpu-rasterization command line:
	328918 (good) - 328924 (bad), 44.0.2396.0
	https://chromium.googlesource.com/chromium/src/+log/77ae9468..c0b9c8f3?pretty=fuller
	Suspecting r328921 "cc: change the GPU rasterization content veto into an MSAA trigger"

Confirmed MSAA is the real cause by enabling rasterization and disabling MSAA (set it to 0) simultaneously via chrome://flags/ or command line --enable-gpu-rasterization --gpu-rasterization-msaa-sample-count=0

A temporary end-user workaround is thus to disable MSAA or the entire GPU rasterization via flags.

Is there a way to control MSAA for content like this? Is this just line drawing?

I haven't tried to repro yet.

This should be hitting the tessellator's cache. I'll look into why it isn't.

It takes 2-3 seconds to tessellate this enormous number of paths, which is not unexpected. However, the paths seem to blow the Ganesh resource cache, so they're re-tessellated every frame.

It doesn't seem to blowing the byte count of the cache; it seems to be exceeding the object count. If I increase that value from 8192 to 32768 (patch attached), render speed on hover is much improved (~10X).

However, this is still slower than software. This is partly due to the large tile size in GPU rasterization. Note that hover in the top tile 300ms/frame as above, but only ~100ms/frame for the bottom tile (where fewer paths fall). This might be a good test case for evaluating different tile sizes.

Deleted: embiggen-ganesh-resource-cache-count.patch 755 bytes

embiggen-ganesh-resource-cache-count.patch 755 bytes Download

Tangent: out of curiosity, I investigated this test case against the (not yet enabled) AA tessellating path renderer, and the results were surprising. I was able to get good results (~30FPS on hover) when the AA tessellator was enabled for all path sizes, but only when the distance field path renderer was disabled. Perhaps the DFPR is filling the cache? Not sure.

This is surprising since the AA tessellating path renderer does no caching at all, and thus should be triggering a re-tessellation and re-upload on every frame, which should be much slower than MSAA. More investigation is required.

This requires:  --force-gpu-rasterization --gpu-rasterization-msaa-sample-count=0 and the attached patch.

Deleted: tess-only.patch 1.9 KB

tess-only.patch 1.9 KB Download

More investigation: the better performance in tess-AA case (no-MSAA, force-gpu-enabled) may have something to do with partial raster. If I do the same test as #6 but with --disable-partial-raster, performance is much worse.

So perhaps we just don't do partial raster in the MSAA case?

To answer my own question, it looks like partial raster is indeed disabled with MSAA: https://bugs.chromium.org/p/chromium/issues/detail?id=629683.

We could consider increasing the resource cache count a la #5, but I'm pretty sure only get close to parity with software raster on this test case by getting partial raster working.

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

commit 01849a55d8dd890c34e2a3cbf3382cff0ac2d258
Author: senorblanco <senorblanco@chromium.org>
Date: Thu Feb 16 15:51:03 2017

GPU: embiggen the Ganesh resource cache count for Skia.

Some content is bumping up against this limit, and hitting some nasty
performance cliffs.

BUG= 687547 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

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

[modify] https://crrev.com/01849a55d8dd890c34e2a3cbf3382cff0ac2d258/gpu/skia_bindings/grcontext_for_gles2_interface.cc

Since some mitigation was done and we no longer have a significant perf regression here, probably best to close this now stagnant issue and open a new one if needed for follow-on work.