Can you say if you have gsync enabled for windowed mode or fullscreen only? Anything special about vsync settings in nvidia control panel?

it's enabled for Windowed mode, so I can game windowed mode and use secondary in this case.

I tried GSYNC+144 and NOT GSYNC+120, and both had problems. So I think GSYNC is actually not related but maybe it would also be.

Nothing else special that I set.

Ok.. I want to upload my chrome://gpu but my comments get deleted, hopefully you can see it in comment 3 or 4

Can't see #3 or 4. Can you just paste the contents in the a text file? The html usually doesn't contain all the information (save as html for chrome:// pages is kinda broken).

Here's gpu as a txt

Deleted: gpu.txt 27.2 KB

gpu.txt 27.2 KB View Download

I'm having this same problem and I found a post in forums describing the same thing here:

https://productforums.google.com/forum/#!topic/chrome/nXh3a87jSzw

It only happens in Chrome (Edge plays the same stream without skipping frames) and it only happens when the stream is displayed on the secondary 60hz monitor. When the stream is playing on the primary 144hz monitor, no frames are dropped, but once I move it over to the other screen, it constantly drops frames.

If I change my primary monitor to 60hz, the problem stops, so it must be specific to having two screens with different refresh rate.

My chrome://gpu details are attached.

Deleted: chrome-gpu.txt 14.5 KB

chrome-gpu.txt 14.5 KB View Download

I can confirm the exact same happens to me. 60hz monitor + 144hz monitor dual setup, Nvidia GPU (although 60hz monitor is running off integrated intel graphics)

The 60hz monitor produces skipped frames on twitch streams and youtube videos at 60fps. Move the window over to 144hz monitor and no frame skips.

issue is not present with firefox and microsoft edge.

I can haz trace?

I'm not sure we correctly deal with using the proper BeginFrame source all through the pipeline.

I've got video game windowed-fullscreen with chrome tracing above it on primary 144hz gsync monitor. Twitch in chrome window on 2nd 60hz monitor. Focus moves to the twitch window near the start of the trace. The video is speeding up slowing down constantly during the trace.

Deleted: trace_badvsync.json.gz 4.9 MB

trace_badvsync.json.gz 4.9 MB Download

The scheduler irregularity is clearly visible just in the LayerTreeHostImpl frame dots.

Short CSS animations are being added that run at 144hz. For several frames, the GPU thread consumes the frames at 144hz but suddenly starts blocking at 60hz. It's almost as if vsync blocking is disabled for a while, but then suddenly locked to the secondary monitor.

+jbauman, +stanisc: What's our current vsync blocking behavior with secondary monitors on Windows 10?

Separately, is there any way to hook BeginFrames up to the monitor they are actually on? If we can't report the correct vsync interval to the video decoder, it'll have a harder time selecting which frame to display.

I've been looking at a similar setup. My understanding is v-sync refresh rate is locked to the primary monitor. But the actual blocking happens inside D3D present because we tell D3D to sync presentation with the next frame. So we can't fix this by fixing the v-sync along.

Weird...in FrameSinkManagerImpl we pick a BeginFrameSource and stick with it unless a FrameSink is reparented. 

I tried to follow these: 

Type Control Panel in the search box.
Click Control Panel.
Click Power Options.
Click Choose what the power buttons do.
Click Change settings that are currently unavailable.
Scroll down to Shutdown settings and uncheck Turn on fast startup.
Click Save changes.

But there's no fast startup option for me. Might be my windows version, as it's Win 10 Pro, or my hardware, idk.

 Issue 680639  is relevant to this.

If you need more reproducible cases, I'm also affected. Attaching my GPU.txt

Of note: the situation improves with HW acceleration disabled in options.

Deleted: chrome-gpu.txt 12.4 KB

chrome-gpu.txt 12.4 KB View Download

Checked possibly related issue: https://bugs.chromium.org/p/chromium/issues/detail?id=724026

For me, applying --disable-direct-composition does not help with the issue, so it seems like something different.

I figured out another way to repro bad behavior consistently. Run game on primary monitor with gsync with the game running at low fps like 15 or something. Chrome video on second monitor also runs at very low fps. This failure mode doesn't really get out of sync just is incredibly jerky.

This also happens on single-monitor too. The GSYNC windowed mode forces all the windows in the background to tolerate variable VSYNC intervals.  

1. View http://www.testufo.com in the background

2. Run a game in GSYNC windowed mode, make it the focus.

3. The framerate of Chrome runs much jerkier than it should be.

I think that variable refresh rate support should be added to HTML 5.2 eventually.   

But even without that, mitigations should be added when Windows forces the Desktop into a variable-VSYNC mode (each refresh cycle can have its own interval, with unpredictable time between VSYNC).   Chrome compositing should automatically be able to detect this condition and run smoothly to its best of ability.

I reproduced this with a similar setup - 144 Hz GSYNC primary and 60 Hz secondary - Chrome on secondary and a game in windowed fullscreen mode on primary. I also saw that making Chrome fullscreen on secondary monitor causes a lot of jank in the game on primary monitor.

The crux of the problem seems to be that we tick at 144 Hz even though the swap chain allows 60 fps on the secondary monitor. We extract vsync parameters from DWM, and DWM uses the primary monitor's refresh rate to drive composition.

Possible solutions:
a. Use MonitorForWindow to get the HMONITOR and get the refresh rate from that. We already have this implemented for the "legacy" vsync path.
b. Use IDXGIOutput::GetDesc to get the HMONITOR instead. Don't know if there's an advantage to that.
c. Use a separate thread to call IDXGIOutput::WaitForVblank and use the timing to estimate interval.
d. Use the swap chain's frame latency waitable object to drive BeginFrames.

Option "c" is very similar to what GPU V-Sync does. You could probably adopt the GPU V-sync solution to fix this issue. See GpuVSyncProviderWin class.

GpuVSyncProviderWin is being removed in crrev.com/c/1065808. I'm hoping that once OOPD (Display stuff in GPU process) is the default we can experiment with better vsync logic (GpuVSyncProviderWin or WaitForVBlank) since the plumbing will be easier.

For now, I'm leaning towards option a. since it's hard to imagine that the extra precision in vsync interval is actually useful given the overhead of propagating the value back.