The description has the incorrect graph (from the stable channel instead of dev). Here's the link for the dev channel:

https://uma.googleplex.com/timeline_v2?sid=b14c83cf5b3363732f774b0a64a58d71

Adding a few folks that might know what's going on since this is Windows specific.

Given when the regression occurred, I suspect something in the following range:
https://chromium.googlesource.com/chromium/src/+log/52.0.2715.0..52.0.2717.0?pretty=fuller&n=10000

jbauman noticed that there was an *improvement* at the 50th percentile for DrawDuration.
I also noticed that PrepareTiles performance regressed and improved similarly.

Here's a link that includes the 50th and 99th percentiles:
https://uma.googleplex.com/timeline_v2?sid=d9a97aa4844c7da52415f75a0cb0fb6e

I was wondering if it could be related to the x64 as default switch, but I haven't been able to get those metrics split by bitness to load ... yet. https://uma.googleplex.com/timeline_v2?sid=fb741d8a10f735d41baac7e6df326d9f

On the original graph it looks like Linux and ChromeOS have similar regressions around the same time for Scheduling.Browser.DrawDuration. Is this metric likely to be related to compositor FPS? It seems like it would. If so then this isn't actually a Windows-only regression.

The type of pages that lead to a Scheduling.Browser.DrawDuration of 0.2 ms are likely to be completely different from those that lead to a Scheduling.Browser.DrawDuration of 10 to 20 ms. It could be, for instance, that scrolling of simple pages is faster but rendering of WebGL content is slower.

Unfortunately that range contains 675 changes. I scanned through them and found the changes that I thought were most likely to be related, although they are all highly speculative and I might easily have missed the culprit. The first change seems like it has potential, but I don't really know.

021c0f9 Enable rendering pipeline throttling by default
675f8b4 Fix underflow and av/sync issues in low delay and stall presence.
ae45161 use new skia imagefilter-ctm handling
ef5fb89 Add place holder to move gfx::Display/Screen to ui/display
b4fc945 Merge OffscreenCanvasRenderingContext into CanvasRenderingContext
f79f4d6 Don't restart the ImageQualityController timer unless it is already half over.
1ee5b84 ReleaseOutputBuffer to surface back and front buffers where possible.
836d818 Switch DrawImage to sk_sp<>
8f77f9e Vulkan renderer now can properly swap buffers and destruct cleanly.
1517f16 Fixed scrolling for mixed-valuator mouse

Various rolls of skia, ANGLE, and WebGL

Well, it wasn't caused by x64 default, but it does seem to break to be x86-only. I'm not sure if that really tells us much. https://uma.googleplex.com/timeline_v2?sid=96341c738a1fefb367996db8e819cb8c

Moving this nonessential bug to the next milestone.

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

This issue has been moved once and is lower than Pri-1. Removing the milestone.

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

It's interesting that the dev channel and stable channel show a spike at the same time. Was there a driver issue or something? In any case, dev channel seems to have recovered. Tim, if I'm reading that correctly, should we close w/ WontFix?

I agree that this looks like it has recovered.
There might be a separate small regression in Scheduling.Renderer.DrawInterval near the end though (in Beta).

I'd be fine calling this WontFix at this point.

Graphs have magically recovered. Closing as WontFix.