For your convenience I have hosted a copy of the above test case here: https://bl.ocks.org/mbostock/raw/58cc9fb39d3e1fef81eb8fb557e08c96/3f181d1968e2bbdb649417c310415e262f1c8621/

Confirmed. We need a bisect because I am quite certain that this will point to a Skia change, or enabling of GPU.

I can repro on Linux.  Requires GPU rasterization.

Bisect results:

You are probably looking for a change made after 423961 (known good), but no later than 423968 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/5974cb6cb046616fdbff93b96cdbdcf9bb5e297e..e37b80174ec1a365487892e3159965c0944828fb

Skia roll: https://chromium.googlesource.com/skia.git/+log/d207884bf5d1..221a4bb55b51

Main suspect: https://chromium.googlesource.com/skia.git/+/6ca48820407244bbdeb8f9e0ed7d76dd94270460

jvanverth@ PTAL.

SKP capture attached.

Deleted: layer_0.skp 2.9 MB

layer_0.skp 2.9 MB Download

index buffer overflow?

Making a guess here… but if the circles are approximated as octagons, and you use a uint16_t to index vertices, then you’ll run out of space with 1 << 16 = 65,536 points = 8,192 circles, which is consistent with the lower bound I saw to reproduce the issue.

This is probably related to 688582 and 684112.

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

commit 8cefe40ab094bfbea532761dad1a857eb3d4b831
Author: Jim Van Verth <jvanverth@google.com>
Date: Thu Feb 09 17:29:31 2017

Don't batch circles and circular rrects beyond index limit

BUG= skia:6158 ,  chromium:690144 , chromium:688582,  chromium:684112 

Change-Id: I7a6d1fb73cbe6cb4328848acd153ff2505b5fea2
Reviewed-on: https://skia-review.googlesource.com/8256
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>

[modify] https://crrev.com/8cefe40ab094bfbea532761dad1a857eb3d4b831/src/gpu/ops/GrOvalOpFactory.cpp

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

commit 7273c6c6210628e39f02afa086ed025413cf8611
Author: skia-deps-roller <skia-deps-roller@chromium.org>
Date: Thu Feb 09 23:24:58 2017

Roll src/third_party/skia/ 1df161ab8..2c49a4185 (15 commits).

https://skia.googlesource.com/skia.git/+log/1df161ab8a6a..2c49a4185865

$ git log 1df161ab8..2c49a4185 --date=short --no-merges --format='%ad %ae %s'
2017-02-09 bsalomon Remove inner/outer threshold restriction on SkAlphaThresholdFilter.
2017-02-09 kjlubick Prevent waiting for NexusPlayers indefinitely
2017-02-09 fmalita [4fGradient] Relax interval checks for SkGradientShaderBase also
2017-02-09 mtklein exclude _none.cpp in G3 build
2017-02-09 ethannicholas re-land of skslc type constructor cleanups
2017-02-09 bsalomon Temporarily don't mark alpha threshold fp as modulating
2017-02-09 mtklein Don't build sksl if we're not building Ganesh.
2017-02-09 msarett Pixel conversion refactors: use raster pipeline for 565 and gray
2017-02-09 mtklein Make src/effects explicitly optional.
2017-02-09 ethannicholas added support for sk_ClipDistance
2017-02-09 bsalomon Re-enable processor optimization test with some fixes.
2017-02-09 fmalita [4fGradient] Relax interval checks
2017-02-09 herb Remove last use of ktx.h
2017-02-09 robertphillips Fix simple-magnification GM in "--preAbandonGpuContext" mode
2017-02-09 jvanverth Don't batch circles and circular rrects beyond index limit

Created with:
  roll-dep src/third_party/skia
BUG= 690144 ,688582, 684112 

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, see:
http://www.chromium.org/developers/tree-sheriffs/sheriff-details-chromium#TOC-Failures-due-to-DEPS-rolls

CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
TBR=robertphillips@google.com

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

[modify] https://crrev.com/7273c6c6210628e39f02afa086ed025413cf8611/DEPS

I've been running into this issue this past week. Stackoverflow post: http://stackoverflow.com/questions/42101725/svg-chrome-strange-rendering-with-many-circles

demo on plunker: http://plnkr.co/edit/CjOmZIKJOnfFwcJrZuG6?p=preview (this breaks only when I zoom in and out, but in actual code, it breaks as soon as I render)

youtube video of behavior on plunker: 
https://www.youtube.com/watch?v=saAm6Rim0zw&feature=youtu.be

As with the original bug report, the expected behavior shows up on Firefox and safari, and used to work in Chrome until this past week.

Should be working in current Chrome Canary.

I confirm that this is fixed in Canary (58.0.3015.0). Thank you! However, the rendering performance on the test case now appears to be about 10-20x slower than before. Is this expected?

Is that 10-20x slower than before the bug was fixed, or versus M55? Either way it's surprising.

And are you seeing this slowdown on Mac OS or Linux?

Checking Mac OS, it looks to be about the same speed before and after the fix (~3 seconds) on a Mac Pro. Used 56.0.2924.87 as the before case and 58.0.3019.0 as the after.

I am on macOS 10.12.3, MacBook Pro (Retina, 13-inch, Early 2015). I don’t know how to re-install 55, so I can only compare 56.0.2924.87 and Canary (58.0.3019.0).

My recollection is that 56 performed similarly to 55, but the rendering output was incorrect. 58 now renders correctly, but since the fix is about 10x slower on the original test case.

Here are two screen recordings.

Chrome 56.0.2924.87, about two seconds to render:
https://www.dropbox.com/s/bvxundxhhsb5ij6/chrome-56.mov?dl=0

Chrome 58.0.3019.0, about thirty seconds to render:
https://www.dropbox.com/s/vfqr5rvyesdpcxk/chrome-58.mov?dl=0

One possibility I can think of is that we are now breaking up the circle rendering into multiple batches, rather than one big batch. Perhaps the multiple draws are causing a slowdown.

I was curious if this was a Retina-specific performance issue, but it does appear so as I am able to reproduce this regression on an older desktop iMac with no issue.

Chrome 54, 1.57 seconds:
https://www.dropbox.com/s/2rkag68pt0popwb/chrome-desktop-54.mov?dl=0

Chrome 56, 1.63 seconds:
https://www.dropbox.com/s/y7spzbolj06q7a5/chrome-desktop-56.mov?dl=0

Chrome 58, 14.9 seconds:
https://www.dropbox.com/s/g1nnqstz4uue7ai/chrome-desktop-58.mov?dl=0

Correction: it does NOT appear to be a Retina-specific issue.

Is it possible that Chrome 58 is falling back to sw rasterization on your system? chrome://gpu would tell you if so.

It does not appear so. The summary output on both Chrome 56 and 58 appears the same, all green:

Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Hardware accelerated
Rasterization: Hardware accelerated
Video Decode: Hardware accelerated
Video Encode: Hardware accelerated
VPx Video Decode: Hardware accelerated
WebGL: Hardware accelerated
WebGL2: Hardware accelerated

If the full output would be helpful, let me know and I can attach.

I feel like there's something else going on here -- I don't see any slowdown on my MacBook Pro (15 inch, mid-2014), either.

Not a statistically valid survey to be sure, but here are seven people who confirmed the slowdown in Canary:

https://twitter.com/jakemauer/status/834140195834322944
https://twitter.com/o_gonzales/status/834140160417755137
https://twitter.com/bhive01/status/834139948370366464
https://twitter.com/twhitbeck/status/834139840337866756
https://twitter.com/JanWillemTulp/status/834139374359031808
https://twitter.com/benelsen/status/834139197430779905
https://twitter.com/sharoz/status/834138100934787073

There was one report not confirming the slowdown:

https://twitter.com/huy/status/834141674003533824

Here's a link to a build of recent Chromium without the fix. Could you run it and see if it has the slowdown?

https://drive.google.com/open?id=0B5Ut-o-fkeGqQzNtMUk5dUU2LUU

Here’s a weird thing: the slowness goes away if I reload the page with the developer tools open! With the console open, or using the performance profiler to measure the page, it only takes about 2-3 seconds to render. But in the normal case it still takes 15-20 seconds.

I tested your build of Chromium without the fix, and it was fast with the developer tools open, and slow with the developer tools closed. (And the rendering output was bad, as expected.)

It sounds like an unrelated issue to the fix. Can you file a new bug and for now assign it to me?

I don’t have the capability to assign issues, but I’ve filed this:
https://bugs.chromium.org/p/chromium/issues/detail?id=695466

Thank you!

Is there an estimate for when this fix will be available on Stable channel?

 Issue 699113  has been merged into this issue.

We probably want to merge to 57, yeah? What's the fix? Is it pretty small and safe?

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

commit ae9cc5d3588d52f4b371b55845704b25d88cf06d
Author: Brian Salomon <bsalomon@google.com>
Date: Tue Mar 07 16:20:54 2017

Don't batch circles and circular rrects beyond index limit

M57 Cherry pick

BUG= skia:6158 ,  chromium:690144 , chromium:688582,  chromium:684112 

Change-Id: I7a6d1fb73cbe6cb4328848acd153ff2505b5fea2
Reviewed-on: https://skia-review.googlesource.com/8256
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-on: https://skia-review.googlesource.com/9383
Reviewed-by: Brian Salomon <bsalomon@google.com>

[modify] https://crrev.com/ae9cc5d3588d52f4b371b55845704b25d88cf06d/src/gpu/ops/GrOvalOpFactory.cpp