I can repro on my laptop. I just did a quick check to see if my transfer buffer changes were to blame, but it seems like no. We should bisect.

kbr@ pointed out and I've verified that this is a duplicate of  bug 882317 . The fix was merged to 70 but not 69.

Testing in Chrome 71.0.3561.0, I am still seeing framerate issues.  For example, open:
https://demo-c.dev.onshape.com/documents/d818d48b6a05a7ce5b5d8128/w/302b518f78a8bbf5fad4f8f8/e/20e539e2c5b1626d10c9aa27?enableFpsTest
Then hit the "Execute FPS Test" towards the bottom right.

In Chrome 68 I see about 44 FPS on my computer.  In Chrome 71, I see about 31 fps, which is worse performance than I have been seeing in Chrome 69.  Chrome 70 _does_ look good however.

I will try to find an issue logged against 71.  If there is not one, I can log a new bug against 71.

Let's just reopen this bug and re-triage it against M71.

Thanks for filing it, by the way, and please test early access Chrome releases so we can catch regressions like this earlier in the development cycle. We're not sure how the regression wasn't caught by our automated performance testing infrastructure but are going to work to make sure future regressions are caught.

I'm seeing:
~68.0.3440.106 ~561733 - g 50fps
 69.0.3497.100  576753 - b 30fps
~70.0.3538.22  ~587811 - b 30fps
 71.0.3561.0    593801 - g 50fps

so apparently I can't reproduce the issue on 71.

A bisect with -g 561733 -b 587811 points to  issue 882317  as mentioned in #3.
https://chromium.googlesource.com/chromium/src/+log/dba5d7b0a7e5d683e98eaec38bd0acf468f62214..09ae405971824864d744b7ae39de7c75773a8816

Hm, actually it looks like performance on my machine for 71.0.3561.0 is a little lower than 68 - maybe about 45fps.

It's actually much easier to tell watching the animations on https://webglfundamentals.org/ . I'll try a bisect on that one.

Actually, webglfundamentals looks good in 593801 when I bisect, but on 71.0.3561.0 (Official Build) canary (64-bit), it looks bad. Wonder if a finch trial, or something else about my user profile, is to blame here.

oh, I think it was just because my canary window was bigger than my bisect window.

fullscreen, the performance in 68 and 71 look similar to me.

This is still an issue

Here's another example

https://threejs.org/examples/webgl_geometry_minecraft.html

Runs smooth 60fps in Firefox
Runs janky 54fps in Chrome

Mid 2014 MacBook Pro with screen at 1680x1050
MacOS 10.14
Chrome: 71.0.3567.0 (Official Build) canary (64-bit)
(and stable 69)

Can you check the performance in 68 to see whether it is a regression or just a case where Firefox is faster?

I am no longer seeing my issue in 71.0.3566.0.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Still needs feedback from gman

You can just try the WebGL Aquarium

http://webglsamples.org/aquarium/aquarium.html

It's running at a janky 50fps on 69 and 71 with only the default 500 fish. In 68 it ran at 60fps on the same machine with 5000 fish

Running bisect I get

python bisect-builds.py --use-local-cache -a mac -g 579000 -b 589893 -- --no-first-run --user-data-dir=delme-chrome https://webglsamples.org/aquarium/aquarium.html
Downloading list of known revisions...
Saved revisions 15734-596124 to /Users/gregg/temp/delme-chroium/.bisect-builds-cache.json
Downloading revision 583985...
Received 85799986 of 85799986 bytes, 100.00%
Bisecting range [579001 (good), 589885 (bad)], roughly 10 steps left.
Trying revision 583985...
Revision 583985 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 581149...
Bisecting range [579001 (good), 583985 (bad)], roughly 9 steps left.
Trying revision 581149...
Revision 581149 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 580362...
Bisecting range [579001 (good), 581149 (bad)], roughly 8 steps left.
Trying revision 580362...
Revision 580362 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 579671...
Bisecting range [579001 (good), 580362 (bad)], roughly 7 steps left.
Trying revision 579671...
Revision 579671 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 579984...
Bisecting range [579671 (good), 580362 (bad)], roughly 6 steps left.
Trying revision 579984...
Revision 579984 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 580124...
Bisecting range [579984 (good), 580362 (bad)], roughly 5 steps left.
Trying revision 580124...
Revision 580124 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 580211...
Bisecting range [580124 (good), 580362 (bad)], roughly 4 steps left.
Trying revision 580211...
Revision 580211 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 580271...
Bisecting range [580211 (good), 580362 (bad)], roughly 3 steps left.
Trying revision 580271...
Revision 580271 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 580235...
Bisecting range [580211 (good), 580271 (bad)], roughly 2 steps left.
Trying revision 580235...
Revision 580235 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
You are probably looking for a change made after 580211 (known good), but no later than 580235 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/5b35992cbe828ddf356ab3296ef9106f01a779c3..26c72fb5f3c5e7f95bac3bf0c68f10301dd66cf1


note that the bad version on my machine starts at around 40fps for 500fish and if it's lucky will go up to 60 but upting to 1000 fish will slow down. The good versions start at 60fps immediately and will stay at 60fps up to 5000 fish. Clicking 10000 fish will be 57-60fps

Okay, testing the lastest Canary 71.0.3568.0 (Official Build) canary (64-bit)
the problem seems mostly fixed. It's not as smooth at 68. With 5000 fish in 71.0.3568.0 is 60 but drops to 57 on and off whereas in v68 5000 is a solid 60

The bisected regression range includes this CL, which makes it very clear that there would be a big temporary regression:
https://chromium.googlesource.com/chromium/src/+/989f7a704c225521f08b2a0d7f64c619ba8aea29

I suspect the remaining regression is expected, though - it's probably this change that was needed to stop driver crashes (bug 863817):
https://chromium.googlesource.com/chromium/src/+/0e3bceb8d188242a2d5be76598a0d010fcca86d6
However we could still bisect to make sure this is the case (I don't have time to do it now).

Reducing to P2 since the big regression is gone.

Linking to previously-merged-into  Issue 882317  since the hope was that that would reduce the impact of the workaround from Issue 863817.

We should see whether we can reduce the amount of additional flushes done for Issue 863817.

Re-testing on a Late 2013 MacBook Pro with NVIDIA GPU (about:gpu follows), the Aquarium is running at a solid 60 FPS for both 500 and 1000 fish on both Chrome 72 (canary) and 70 (stable). Mostly solid 60 FPS on a mid-2015 MacBook Pro with AMD GPU (Radeon R9 M370X).

I'm not sure how to make progress on this report. Is there a test case that more reliably shows the performance regression?

Mac triage: WontFix issue without repro steps or a test case (per #20).