I don't know why most of the input data was missing from the trace but I managed to make sense of the trace anyway. The right-mouse press at 32.5 s seems to be the one that brought up the context menu because dwm and Chrome go from doing work every ~33 ms to every ~16 ms at that point. It's quite clear.

The GPU process main thread is being throttled by dwm which is being blocked waiting for a packet to be processed. I think this works out to "comment #41 is correct", but now what?

Note that the "CommandBufferService:PutChanged" task in the chrome trace maps to chrome_child.dll!gpu::CommandBufferService::Flush, which is on the GPU process wait stack below. So, the ETW data gives more information about exactly why that task takes so long.

Here are more details of what I can see in the ETW trace:

The GPU process main thread (chrome.exe (1172) 6016) is blocked, typically for ~31 ms (sometimes 100 ms!) on this call stack:
chrome_child.dll!gpu::CommandBufferService::Flush
chrome_child.dll!gpu::gles2::GLES2DecoderImpl::DoCommands
chrome_child.dll!gpu::gles2::GLES2DecoderImpl::DoCommandsImpl<0>
chrome_child.dll!gpu::gles2::GLES2DecoderImpl::HandleCopySubTextureCHROMIUM
chrome_child.dll!gpu::gles2::GLES2DecoderImpl::HandlePostSubBufferCHROMIUM
chrome_child.dll!gpu::PassThroughImageTransportSurface::PostSubBuffer
chrome_child.dll!gpu::DirectCompositionSurfaceWin::SwapBuffers
chrome_child.dll!gpu::DirectCompositionChildSurfaceWin::SwapBuffers
chrome_child.dll!gpu::DirectCompositionChildSurfaceWin::ReleaseDrawTexture
dxgi.dll!CDXGISwapChain::[IDXGISwapChain4]::Present1
dxgi.dll!CDXGISwapChain::PresentImpl
dxgi.dll!CDXGISwapChain::PresentImplCore
dxgi.dll!CDXGISwapChain::FlipPresentToDWM
dxgi.dll!CFlipPresentToDWM<CDXGISwapChainWrapper>::FlipPresentCore
d3d11.dll!NDXGI::CDevice::Present
d3d11.dll!dxrt11::Direct3DSurface::Release
igd10umd64.dll!<PDB not found>
d3d11.dll!NDXGI::CDevice::PresentCB_PreWDDM2
d3d11.dll!NDXGI::CDevice::PresentCB
win32u.dll!NtGdiDdDDIPresent
ntoskrnl.exe!KiSystemServiceCopyEnd
win32kbase.sys!NtGdiDdDDIPresent
dxgkrnl.sys!DxgkPresent
dxgkrnl.sys!DXGCONTEXT::Present
dxgkrnl.sys!SubmitPresentHistoryTokenPreparation
ntoskrnl.exe!KeWaitForSingleObject


It is readied (allowed to run) by dwm.exe (1140) 2180 on this call stack.
ntdll.dll!RtlUserThreadStart
kernel32.dll!BaseThreadInitThunk
dwmcore.dll!CConnection::RunCompositionThread
dwmcore.dll!CPartitionVerticalBlankScheduler::ScheduleAndProcessFrame
dwmcore.dll!CPartitionVerticalBlankScheduler::ProcessFrame
dwmcore.dll!CCrossThreadComposition::PreRender
win32u.dll!NtDCompositionBeginFrame
ntoskrnl.exe!KiSystemServiceCopyEnd
win32kbase.sys!NtDCompositionBeginFrame
win32kbase.sys!DirectComposition::CConnection::BeginFrame
win32kbase.sys!CTokenManager::ReleaseToFrameInternal
win32kbase.sys!CTokenQueue::ReleaseTokensToFrame
win32kbase.sys!CFlipToken::InFrame
win32kbase.sys!CFlipToken::SignalGpuFenceAndPresentLimitSemaphore
win32kbase.sys!CompositionSurfaceObject::SignalPresentLimitSemaphore
win32kbase.sys!CFlipExBuffer::SignalPresentLimitSemaphore
win32kbase.sys!SignalPresentLimitSemaphore
ntoskrnl.exe!KeReleaseSemaphore


Meanwhile that dwm thread waits three times:
1) It waits for a v-blank and is readied, after ~16 ms, by dxgmms1.sys!VidSchiProcessDpcVSyncCookie.
2) That thread decides that it isn't really ready so it waits for ~7-8 ms and is then readied by win32kbase.sys!CTokenManager::TokenThread, another dwm thread
3) The other thread is readied by dxgmms1.sys!VidSchiProcessDpcCompletedPacket (that thread slept for ~33 ms)
4) The original dwm thread then waits another ~8 ms is readied by dxgmms1.sys!VidSchiProcessDpcVSyncCookie, and then the cycle repeats

So, we're getting v-blank messages at 60 fps, but we have to skip some of them because we're waiting on a packet. A present packet? A DMA packet? It's inside of dxgmms1.sys!VidSchiProcessDpcDmaPacket but I don't know what that really means.

It's too bad the DXG data isn't showing up in the trace viewer - maybe that would clarify things.

The trace contains much more information - more call stacks - but I tried to summarize to just the most salient details.

re c#47,

Yeah UIETW could not reg the shortcut so I had to improvise.
I will check if u updated it tommorrow and run another trace (to file).

PS : this issue kinda feels like the various reports of games running @ half fps in borderless fullscreen with 16299. We might have to wait for a MS CU... Still FF fullscreen implemntation is doing fine. 

Can you link to reports of games running @ half fps? It does sound related.

Another trace would be nice, but is probably not crucial. I think I got what I need.

New trace with GPU data (seems the new WPT did the trick) :
https://drive.google.com/file/d/0B1i3CbzCy4bIVUpKa2l2Q1l3VWs/view?usp=sharing

Interactions in .txt :
- 0 to 5s - Starting the trace with video playin in fullscreen and frames dropping
- 5 to end - left clicks to display context menu, framedrops stops, ending he trace.

The only changes compared to trace#2 are the latest chrome stable rlz and new 388.10 nvidia drivers (but it shouldn't matter since chrome is using my Intel GPU)

As for links related to fps issues in games with 16299 :
https://forums.guru3d.com/threads/geforce-388-00-whql-game-ready-download-discussion.417491/page-5#post-5485232
https://forums.guru3d.com/threads/geforce-388-00-whql-game-ready-download-discussion.417491/page-4#post-5484864
https://answers.microsoft.com/en-us/windows/forum/games_windows_10/frame-rates-may-drop-on-some-directx-9-games-at/c7e47851-06bc-408a-a355-231a2c23181a?auth=1
And a bunch in
https://forums.geforce.com/default/topic/1026749/geforce-drivers/window-10-fall-creators-update-feedback-thread-released-10-17-17-/

Have you tried this solution from https://answers.microsoft.com/en-us/windows/forum/games_windows_10/frame-rates-may-drop-on-some-directx-9-games-at/c7e47851-06bc-408a-a355-231a2c23181a?auth=1:

1. From the Start Menu, right-click the affected app and select More > Open File Location. File Explorer will open to the app’s location.
2. In File Explorer, right-click the app and select Properties.
3. On the Compatibility tab, check the box to Disable fullscreen optimizations.

As I said in c#39, I did. Frames ar still dropping.
I also tried disabling win10 game bar and video optimisations in battery settings.

It sounds like a GPU or Media person needs to take a look at our presentation stack for full-screen on Windows. 

+dansanders@, do you know who a good person to look at Windows media issues is?
+vmiura@, do we have anyone looking at Windows GPU issues at the moment?

TL;DR - can we enable triple-buffering when in full-screen mode for tomorrow's canary? Is this any easy thing to do?

I looked at the latest trace with GPU information and it confirms our suspicions. Here's what we know:

When playing full-screen video with no windows or menus in front the operating system "upgrades" our swap chain to display our buffers directly instead of copying them. This has been the case for a while, and it normally works smoothly. This can be seen in the latest trace (and on my *spring" Creators Update workstation) by noting that when there is no window or menu in front of the video then dwm uses no GPU time - it must be displaying the front buffer directly. Note that when this happens our buffer necessarily gets locked until the next frame is presented.

When playing full-screen video with a window or menu in front the system can't display our buffer directly. Instead dwm copies it to the system back buffer, and presumably returns our buffer to us immediately.

So, in the no-window/no-menu case our buffer is probably locked for ~16 ms longer. This probably cuts into our headroom for generating the next frame, but it works fine. Until now, on some machines.

Now, in the no-window/no-menu case we are repeatedly blocking inside of chrome_child.dll!gpu::CommandBufferService::Flush, which calls gpu::DirectCompositionChildSurfaceWin::SwapBuffers (full stack above) for 33 ms at a time. We are readied by dwm. Clearly if dwm blocks our SwapBuffers call for 33 ms every time (yes, every time) then we can't possibly manage more than 30 fps.


This appears to be a Microsoft bug (see https://answers.microsoft.com/en-us/windows/forum/games_windows_10/frame-rates-may-drop-on-some-directx-9-games-at/c7e47851-06bc-408a-a355-231a2c23181a?auth=1) or else the timing was perturbed. The most likely workaround is for us to use triple-buffering instead of double-buffering.


I think we should switch to triple buffering in at least some cases (full screen?) to see if that solves the problem. In parallel we should follow up with Microsoft to see if they have any other suggestions and if they agree that this is a bug. It seems that SwapBuffers repeatedly taking 33 ms to return is necessarily an OS bug.

It would be helpful if we could discover what it is that triggers this behavior on some Fall Creators Update machines but not all.

Bruce, were you asking if you can enable triple buffering via a D3D11/DXGI feature, or were proposing we do this internally ourselves?

FWIW the ANGLE team has one contact we correspond with at Microsoft who has been very good at relaying bug reports.

I'm not totally sure what I'm asking but since the slowdowns happen because a buffer is being locked for 33 ms it seems that enabling triple buffering would probably work around this glitch. Asking for Microsoft help would be great. I can file a formal bug report but sometimes informal contacts are better at this stage in the investigation.


I attached a GPUView screenshot from the latest trace, zoomed in around 4.1 s (the transition from slow to fast) with v-blanks enabled (F8 - the vertical blue lines).

You can see the GPU work (black and blue squares) happening well in advance of the v-blanks, and yet the swap packets (diagonal grid rectangles) only happen every second frame. The GPU is doing more work in the 60 fps case, and yet it keeps up perfectly.

Deleted: Bug775898_YouTubeFrameDrops.PNG 23.2 KB

	Bug775898_YouTubeFrameDrops.PNG 23.2 KB View Download

Yes, this is very clearly a problem.

It should be possible to choose to use triple buffering in ANGLE on D3D11/DXGI. I'm not sure how much work we would have to do manually to test this. See the docs here:

https://msdn.microsoft.com/en-us/library/windows/desktop/hh404528(v=vs.85).aspx

The BufferCount parameter allows us to select the number of swapchain buffers.

EGL doesn't expose this, so if we decide we want to increase the buffer count, we'd either have to have that be the default or expose an ANGLE EGL extension to control the buffer count via an EGL config.

I'll contact you offline about talking to our MS contact.

Any progress or news from MS ? 

On my end I tried the lastest WHQL nvidia driver (388.13 released today), same issue.

Considering OP's gfx card (NVS300) and mine (Intel HD3000), I was suspecting some kind of weird bug involving Win10 CFU + old dx11 compatible gfx cards that are 10.1 features wise but I see ppl left and right posting issues kinda similar to ours and they prolly have newer hardware.
https://forums.guru3d.com/threads/nvidia-geforce-388-13-whql-driver-download-discussion.417625/page-2#post-5487137
https://www.reddit.com/r/chrome/comments/79jlh0/bbc_iplayer_fullscreen_videos_stutter_after_the/

It seems MPC-HC, MadVR, LAV filters guys also got some issues with CFU but they got options/settings to go around (e.g. forcing copyback buffer AFAIK). 

Oh well...I'll report back after the next Win10 CFU critical update (14th of november prolly). 

No updates or news. Unfortunately progress may be slow at this point as we try to figure out exactly what is going on, and go back and forth with Microsoft.

Thank you for the third trace. It is perfect. I'm glad that you were able to capture the GPU data (I did not know that having the latest WPT was required for that - you learn something every day). The input data also showed up, and the trace brief and to the point.

I ended up focusing on the one second period around when you brought up the context menu, with the remaining seconds being useful padding to ensure that the patterns actually continue.

Microsoft support is swamped so there may be delays in getting assistance, even through formal support channels

#58: For DirectComposition, we create the swap chain in Chrome and don't use ANGLE for it: https://cs.chromium.org/chromium/src/gpu/ipc/service/direct_composition_child_surface_win.cc?l=115

So, we shouldn't need anything from ANGLE, I think.

We still can't reproduce this bug but we have some ideas on how to work around it. Can somebody who can reproduce this bug try running Chrome with a couple of extra switches. First:

--in-process-gpu

This should not affect the bug, it's just a necessary initial test to see if it affects the results with and without a context menu up. I would expect that with this switch the videos will still run at 60 fps with a context menu up and <30 fps without (when running full-screen).

The next test should be this pair of switches:

--disable-direct-composition --in-process-gpu

The "--disable-direct-composition" switch is the one that I really want to test, but it is ignored if "--in-process-gpu" is not specified. I am hopeful that this pair of switches will avoid the bug, by disabling the direct composition path which appears to trigger the DWM bug.

My chrome immediatly crashes with the --in-process-gpu switch (.dmp attached). 

I tried removing the couple flag switches I had (--enable-tab-audio-muting --trace-export-events-to-etw) to get the cleanest cmd line possible in chrome://gpu/(i.e. "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end) but it still crashes.   

Suspecting my gpu (Intel HD 3000) I also tried ignoring the gpu blacklist to no avail.

Deleted: 0b0f0e56-7fee-4497-bc10-a82fc8bacce1.dmp 150 KB

0b0f0e56-7fee-4497-bc10-a82fc8bacce1.dmp 150 KB Download

Oops. Yep, it looks like --in-process-gpu is not supported in the Chrome versions that we ship (it worked in my development build). We'll have to ship a canary version that supports --disable-direct-composition without requiring --in-process-gpu.

Columbo's hat ON

Browsing thru FF's bugtracker to see if I could find stuff related to sandybridge and video buffers, I stumbled upon this one :
https://bugzilla.mozilla.org/show_bug.cgi?id=1405110
Bugfix, Win7 generalised later to all platforms : https://bugzilla.mozilla.org/show_bug.cgi?id=1409141

Dunno if our framedrop bug is related to this one but worth a look. 

Columbo's hat OFF

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

commit 51709eb84ed3eeaa539acca01b3e199963991cec
Author: Bruce Dawson <brucedawson@chromium.org>
Date: Wed Nov 08 19:47:25 2017

Propagate disable-direct-composition switch to GPU process

The disable-direct-composition switch can be handy for working around
bugs but it can currently only be set programmatically - the browser
process doesn't propagate it to the GPU process. That fixes that in
order to allow investigating a specific bug, but also future bugs.

Bug: 775898
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;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
Change-Id: I3c25d2b8b5718cf8c9c5328933ba67e49c66d03a
Reviewed-on: https://chromium-review.googlesource.com/756963
Commit-Queue: Antoine Labour <piman@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Commit-Position: refs/heads/master@{#514912}
[modify] https://crrev.com/51709eb84ed3eeaa539acca01b3e199963991cec/ui/gl/gl_switches.cc

The FF bug doesn't look related, I don't think.

The change referenced in comment #70 means that --disable-direct-composition now works (no need to try using --in-process-gpu). Our belief is that --disable-direct-composition should avoid the problem - it should allow 60 fps video in full-screen without frame drops (at the cost of slightly more power consumption). If you can test with tomorrow's canary (whatever version comes after 64.0.3262.0) that would help guide our efforts.

Partial BUGFIX FOUND ! At least I think... --disable_d3d11 switch

TLDR : disabling the directX11 path (--disable_d3d11 switch) fixes the weird dropped frames (30fps/60fps) bug in fullscreen with win10 CFU and SandyBridge CPU/GPU, a bug probably introduced by  Issue 755722  bugfix. 
https://bugs.chromium.org/p/chromium/issues/detail?id=755722

Detailed explanation : this bug SEEMS to be a side-effect of re-enabling D3D11 path on Win/AMD switchable machines with drivers released after 2016-06. Video playback regressions were expected on some systems by kbr@chromium.org.

Considering this fix has been introduced in Chrome 62.0 (rlz 10/17/2017), I don't know if it's Win10 CFU fullscreen mode or Chrome related. 

Proposed temporary fix : inplementing D3D11 path blacklisting for Intel SandyBridge Driver <= than 05/19/2016 (latest Win10 Windows Updats HD3000 driver 9.17.10.4459).
Con : D3D9 is slower.
Pro : fullscreen framerate is fixed.

Long term fix proposal : considering FF manages to use the D3D11 path without issues, finding out WTH is going on in chromium (adding intermediary buffer ?) or detecting & forcing D3D9 path on sandybridge+Intel GPU systems combo (while maintaining D3D11 path for Win/AMD swichtable machines).

+kbr for that change.

dalecurtis@: let's see whether brucedawson@'s change to allow testing of --disable-direct-composition has an effect. Falling back to D3D9 is probably doing that as a side-effect. We would rather not disable the D3D11 code path again, as the D3D9 path is not our primary focus and has been seen to have various correctness issues on some web pages.

Ok gonna test --disable-direct-composition switch on tmrw canary build and will report back as soon as I can.

PS : AFAIK sandybridge is also the CPU/GPU of a bunch of 2011-2013 Mac products. Considering only Win users reported this issue, old Intel/Nvidia Win drivers and/or WIn CFU must be to blame. Blacklisting D3D11 code path of Intel  GPU using driver version (and not driver date) should do the trick without impacting  AMD switchable systems, I think. 

PPS : as expected, the --disable_d3d11 switch also fixes the framedrop issue in Opera 49.0.2725.34.

--disable-direct-composition switch does fix the issue with Canary 64.0.3263.0

Without the switch, frames are still dropping in fullscreen mode.

Canary Chrome GPU : see attachement
YT video used : https://www.youtube.com/watch?v=BmTtHEe2GuY

Deleted: gpu.html 165 KB

gpu.html 165 KB View Download

Can you also try --disable-direct-composition-overlays (without --disable-direct-composition)?

Do you mean "disable-direct-composition-layers"? That flag was tried already, although with a different syntax:

--enable-features=disable-direct-composition-layers

There is no disable-direct-composition-overlays flag :-(

This one: https://cs.chromium.org/chromium/src/ui/gl/gl_switches.cc?l=114

It controls whether we use child surfaces for hardware decoded video.

Canary 64.0.3263.0 without any switch == dropped frames
--disable-direct-composition == framerate issue FIXED
--disable-direct-composition-overlays == dropped frames
--enable-features=disable-direct-composition-layers == dropped frames
--disable-direct-composition-layers == dropped frames

Latest Win10 CFU Cumulative update (16299.64) did not fix the issue. :/

Dunno what u guys are planning. Reintroducing D3D11 blacklisting ? A direct-composition workaround ? 

If it's Win10 CFU and/or IntelHD3000 driver related, I doubt MS and Intel will do something tbh.

In the past I've had some luck dealing with a similar issue of low frame rate on non-fullscreen apps on Nvidia GPU by disabling Windows fast startup. Steps can be found here: https://www.howtogeek.com/243901/the-pros-and-cons-of-windows-10s-fast-startup-mode/

Can you try that, restart your PC, and let us know if that fixes your problem? Please test without any extra Chrome flags.

Already tried toggling fastboot (I'm running with fastboot OFF atm), it did not help. 
I also tried playing with Intel HD3000 PCI Express power plans and quality slider, Nvidia's settings etc.

Guess I'll have to move on.

Bruce, you seem to be driving most of the efforts here, so assigning to you for tracking. Is there anything we can do for the upcoming M63 launch to resolve this?

We could merge crrev.com/c/756963 to M63 so that --disable-direct-composition will be an effective workaround in M63.

But we really need an actual fix. I have an experimental CL that turns on triple buffering (crrev.com/c/769671) but I don't know if it really works. And, while Microsoft has informally suggested that we should use triple buffering with direct composition always they have not followed through with an explanation or said that this is an official requirement, so our graphics experts seem to be unwilling to always use triple buffering. This means that we need GPU detection code, assuming that we know which GPUs trigger the issue.

I haven't worked with the GPU detection code so advice would be appreciated.

@vmiura can you help connect/advise Bruce here?

I can help. To add GPU-specific code, add an entry to:
src/gpu/config/gpu_driver_bug_workaround_type.h

and reference it from an appropriately structured entry in:
src/gpu/config/gpu_driver_bug_list.json

Then code in various places can reference that workaround.

A recent CL introducing a new driver bug workaround (since reverted, since it didn't work) was https://chromium-review.googlesource.com/750327 .

Isn't it easier to disable direct composition for the affected hardware instead? Triple buffering means one more code path to maintain.

So far there are two reports: #0 with Nvidia NVS 300 GPU and #21 with Intel HD 3000 and Nvidia GT555M Optimus. That's way too few reports to draw conclusions about how widespread this is.

One thing I'm confused about in the original report: it says the GPU is NVS 300 which is a 2006 era GPU with D3D9 support. Do you know why chrome://gpu in #0 says ANGLE is using D3D11?

AFAIK HD3000, Nvidia GT555M and Nvidia NVS 300 are all 2011 era products with D3D 10.1 features support at launch :

https://www.techpowerup.com/gpudb/1257/hd-graphics-3000
https://www.techpowerup.com/gpudb/1955/geforce-gt-555m
https://www.techpowerup.com/gpudb/1452/nvs-300

On my laptop, GPU-Z reports the HD3000 as DirectX 10.1 features compliant and the GT555 as 11.0. (same as nvidia control panel system stats, 11_0 features, 11.2 API)   

As regards the HD3000, an "easier" fix would be to extend the disable_d3d11 workaround to driver older or equal to 9.17.10.4459 (mine atm from windows update) in gpu_driver_bug_list.json. 

An even safer fix would be to use the device_id (VENDOR = 0x8086, DEVICE= 0x0116).

From gpu_driver_bug_list.json :

    {
      "id": 92,
      "description": "Old Intel drivers cannot reliably support D3D11",
      "cr_bugs": [363721],
      "os": {
        "type": "win"
      },
      "vendor_id": "0x8086",
      "driver_version": {
        "op": "<",
        "value": "8.16"
      },
      "features": [
        "disable_d3d11"
      ]
    },



 

Found something new : long story short, running chrome in Windows 8 compatibility mode fixes the issue (without the --disable-direct-composition switch). 

In my case, the Intel driver is probably to blame and/or some weird Win10/Nvidia/Intel combo of driver mess. Only the Arrendale CPU/GPU gen was announced "incompatible" with win10 CFU thou, not the Sandybridge gen. oConsidering OP's issue was with a single NVS 300, I think the underlying issue is "old" gfx drivers and latest win10 fullscreen management. 

I don't know what running in Win8 compatibility mode means chrome wise (does it disable direct compose ? use the dx9 path ?) and if some flags or blacklist rules based on driver version could reproduce its behavior.

My recent tests :
- Digging around geforce forums I've found recent reports (09 and 10-2017) of ppl experiencing apps such as geforce experience or chrome showing all black screen when launched (win10). It reminded me of an unresolved bugreport in this very tracker (chrome would start with a black screen when using the nvidia card on an optimus setup).
- The "fix" proposed on the geforce forum was to run these apps in win8 mode or rolling back the latest Intel driver pushed by windows update. 
- I've installed the geforce experience app to check if I was experiencing the same bug. I did ;
- I tried running chrome in Win8 compatibility mode without any flag or switch and I was no longer dropping half of the frames in fullscreen @1080p60 on YT (about 1,4 % instead of 50 %) ;
- I tried rolling back my intel HD3000 driver to the latest version proposed by Intel website (15.28.24.64.4229, 06/2015 i.e. one year older than my current 9.17.10.4459 pushed by windows update). Black screen in geforce experience and half of the frames still dropping in fullscreen @1080p60 on YT. Win8 compatibility mode fixes the issue.

ATM I'm running geforce driver 388.31 and went back to the latest windows update Intel HD3000 driver 9.17.10.4459 I was using in my trace. I think I'm done testing stuff. I'll run chrome in win8 mode or switch to FF (doesn't drop frames nor need win8 compatibility mode) until MS/Intel/Nvidia get their xxit together or u guys find a workaround.
    
Some linkks :
- A bugreport with symptoms and fixes that look a lot like ours : https://bugs.chromium.org/p/chromium/issues/detail?id=724026
- Blackscreen issue in chrome : https://forums.geforce.com/default/topic/1025457/geforce-experience/geforce-experience-black-screen/post/5220160/#5220160
- Win 8 compatibility mode fix : https://forums.geforce.com/default/topic/1024910/geforce-experience/geforce-experience-black-screen-and-nvidia-icon-taskbar/post/5216159/#5216159
- Intel driver rollback fix (that did not work for my hd3000) : https://forums.geforce.com/default/topic/1025457/geforce-experience/geforce-experience-black-screen/post/5220286/#5220286

I can confirm that running Chrome in Windows 8 mode fixes also the problem for my Nvidia NVS300.

Win8 mode triggers additional driver workarounds in chrome://gpu :
disable_delayed_copy_nv12
disable_direct_composition
disable_dxgi_zero_copy_video

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

commit fbbf434ba94f5e150b0dfc1b830f7829f0e4e177
Author: Sunny Sachanandani <sunnyps@chromium.org>
Date: Tue Nov 21 06:02:11 2017

gpu: Blacklist direct composition on older GPUs.

Older Intel and Nvidia GPUs either cause slow presents or black flashes
with direct composition. Blacklist only those devices which have been
reported to have issues.

R=kbr
BUG=775898,785648

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
Change-Id: I506df99854d7d0d464cea9d0a83336429eeefd4d
Reviewed-on: https://chromium-review.googlesource.com/777854
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#518146}
[modify] https://crrev.com/fbbf434ba94f5e150b0dfc1b830f7829f0e4e177/gpu/config/gpu_driver_bug_list.json

issue 787217 shows some similar issues (or at least benefitted from some of the workarounds mentioned in this page) with a user on a 1070 and up to date drivers, see c#8.

+oetuaho,amalp from nvidia in case there's something they see that is fixable in driver updates / conversations with msft.

Doh, somehow messed up cc.

i have intel hd4000 and nvidia gt620m switchable graphics card and i have the issue. os: windows 10 x64 with fall creators update

chrome stable is not affacted with this issue but dev and canary versions are

tried these flags but not worked
--disable-direct-composition
--disable-d3d11

Regarding comment #98 - did you try --disable-direct-composition with canary? That switch doesn't work in the other versions.

The change landed in comment#94 *should* make canary (as of today) work without requiring any switches. Can all who reported the issue gives this a try if possible and report back? It would be helpful to include what GPU(s) you have in your reply to make it easier to track where the latest fix is or isn't working. Thanks.

It seems the fix has not been added to 64.0.3276.0 either.

Frames still dropping in fullscreen and no mention ot the fix in Driver Bug workarounds nor Problesm detected.

The --disable-direct-composition flag switch still works thou.

Intel HD 3000
Nvidia Geforce GT 555M

Deleted: gpu.html 165 KB

gpu.html 165 KB View Download

Mmmm kinda weird, I've just checked 64.0.3276.0's "gpu_driver_bug_list.json" and the bugfix for my GPU is listed (id 248).

Something must be interfering with it. 

Same thing in 64.0.3277.0 : "disable_direct_composition" feature is not triggered.

Considering "msaa_is_slow" (id 132) does trigger and is based on the same   vendor_id (0x8086), maybe id 248 bugfix also needs the "multi_gpu_category": "active" argument ?

The new additions were tagged as type "windows" instead of "win". I'll upload a CL to fix that.

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

commit 138492abcdb3e0d9369f25868fff4b9dababf915
Author: Bruce Dawson <brucedawson@chromium.org>
Date: Wed Nov 29 00:11:00 2017

Change GPU driver bug list tag from windows to win

Some recent additions to gpu_driver_bug_list.json tagged the workarounds
with os type "windows" when "win" is the correct tag. This fixes that.

I'll investigate adding checks to the script to reject unknown OS types.

Bug: 775898,785648
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;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
Change-Id: I4f9cfb86487385c45fe6a2a8f67c93f711c0f315
Reviewed-on: https://chromium-review.googlesource.com/791850
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#519916}
[modify] https://crrev.com/138492abcdb3e0d9369f25868fff4b9dababf915/gpu/config/gpu_driver_bug_list.json

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

commit f0980d12d3c008a78a2a03109e2b63954f60b680
Author: Bruce Dawson <brucedawson@chromium.org>
Date: Wed Nov 29 05:27:33 2017

Add OS type checking to process_json.py

File adding a workaround to a GPU driver bug the os type "win" was
misspelled as "windows". This caused a one-week delay in testing the
workaround. This adds an OS type check to avoid this error in the
future. It was confirmed that this check would have detected and
prevented the recent error, with this error message:

    Exception: Unknown OS type "windows" for entry 248

Bug: 775898,785648
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;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
Change-Id: Idd1a4266087acbae24cfc6e60ac873f17c7ac7ef
Reviewed-on: https://chromium-review.googlesource.com/791930
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#520018}
[modify] https://crrev.com/f0980d12d3c008a78a2a03109e2b63954f60b680/gpu/config/process_json.py

Thx Bruce, the fix is working as intended in Canary 64.0.3280.0

Is it in time for 63.0 stable or do we have to wait for 64.0 ?

Thanks for verifying the fix, and apologies for the delays. Unfortunately we are too late for M63 except for very high-priority issues which I don't think this counts as, so M64 it is.

M64 it is then (January 23).

Considering it might be a Win10 CFU specific issue and a CU could eventually fix it, is there a way to disable this very fix without disabling every gpu driver workarounds at the same time ? 

--disable_direct_composition=0 should disable the workaround, this is different from the flag mentioned before, note the underscores in place of the dashes

--disable-gpu-driver-bug-workarounds will disable all workarounds, you don't want to do this in general

Is it possible that Microsoft fixed the bug in their latest KB4051963?
See: https://support.microsoft.com/en-us/help/4051963/windows-10-update-kb4051963
Quote: "Addressed a performance regression when users run full-screen Microsoft DirectX 9 games and applications."

I tested again my orginally reported video and the framedrops disappeared after the Microsoft KB Update today. I am running Chrome 62.0.3202.94, so I don't think any fix is implemented there yet, right?
I am able to run the video completely full screen with very little to no framedrops at 1080p60

The description of the Microsoft fix does not sound like it should apply to our scenario because we aren't using DirectX 9. On the other hand, we haven't made any fixes to M62, and there were no known workarounds available in M62 (no command-line fixes, for instance). So, it appears that Microsoft must have fixed it.

Can anybody else test with M62 to see if the problem is fixed for them?

I'd double check that you're not running under Windows 8 compatibility mode. That was the only workaround that exists on M62.

Not on my hd3000. Using your originally reported video, I'm still dropping 33% to 50% frames on current Chrome stable and the latest Win10 CFU CU (16299.98).

It seems the behavior slightly changed thou : more erratic as if from time to time it manages to resync and then loses sync very quickly again.  

On the Canary build (with the disable_direct_composition workaround), my framerate is rocksolid (way less than 1% frames dropped). 

TLDR : maybe "id:249" workaround (old nvidia gpus) is no longer needed but "id:248" one (Intel Sandybridge) must definitely remain.

I checked again my launch link for Chrome and there is no compatibility mode enabled. So for my NVidia NVS 300 the problem disappeared with Microsoft KB4051963

"The Windows product group appears to have a fix that should address the framerate issues that you are encountering. However, the servicing details regarding when a fix for Windows 10 version 1709 have not yet been determined."

So...

1) I will update this whenever the fix ships (presumably first to preview builds and then through regular channels)
2) We will need to have a way to disable the workaround in gpu_driver_bug_list.json so that the Windows fix can be tested so that we can eventually remove the workaround

 Issue 794843  has been merged into this issue.

Note: This can also manifest as a/v sync issues where audio is out of sync with video.

Adding similar issue which may be a dupe.

Yes, this does look similar. 

I'd like to not I've have a quick look at "Microsoft KB4051963", however it refuses a manual install, citing it isn't applicable to my computer. Running windows 10 x64. So either I already have it, or something else has happened.

I'd like to add that I reinstalled in the last two days, and the stuttering issues is still present in Vivaldi. I know this is a different browser, but I'd expect that a windows update would catch it as well.

A Windows fix should go out in February. If that happens then we can think about removing the workaround. This should be fairly straightforward because the bug only appeared in Fall Creators Update and it will be fixed in Fall Creators Update and subsequent versions.

 Issue 811135  has been merged into this issue.

bruce > Is it the update we were waiting for ? 

KB4074588 (OS Build 16299.248)
https://support.microsoft.com/en-us/help/4074588/windows-10-update-kb4074588

(...)
Addresses issue where, in certain hardware configurations, the frame rates of DirectX Games were unintentionally limited to a factor of the display's vertical synchronization.
(...)

I'll give it a test, I think I have other software as well that doesnt seem to be as optimized, like some games and Blender

> bruce > Is it the update we were waiting for ? 

I believe so - it should be.

I tested the update with win8 compatibility turned off and hardware acceleration turned on.
Seems to resolve the problem

Deleted: tragic.png 1.6 MB

	tragic.png 1.6 MB View Download

I have verified that that is the update we have been waiting for. I'm glad to hear that it resolves the issue. Close this as fixed?

I'm reporting the issue is not resolved after the KB4074588 update

This is the stats for nerds, after it took ages to switch into HD:
https://i.imgur.com/wY33dfo.jpg
It even stops to buffer, and I'm on a fiber line that's not being used.

I tested 64.0.3282.140 with --disable_direct_composition=0 on my Sandybridge optimus laptop updated to 16299.248. 

Some frames are still dropped (about 1.3%) and the fact that the "context menu trick" still works (no more drops when win context menu is displayed on top of the video) kinda tells me this is not 100 % fixed (at least for sandybridge ppl. We may aslo require a new gfx driver).

Soooo...not 100 % fixed but that may be sufficient to remove the workaround.

The issue is not resolved for me as well. It works without any problems in Edge and Firefox. 

I just noticed that with Youtube's 136th AVC codec on old videos (https://imgur.com/ROSfzWD) it drops frames only when you go fullscreen and back and only sometimes but with the new 298th codec (https://imgur.com/gJ6KyFL) it starts to drop frames every 2-3 seconds whether fullscreen on or not.


OS: Windows 10 (+KB4074588)
Browser: Chrome 64 (--disable-direct-composition flag is on)
GPU: Intel HD3000

How do you guys check the frame drop through the stats? all I see is solid 60frames, I dont see the drop details in your screenshots, im using FPS meter and it would be more cozy to just use Stats For Nerds instead

For me, it's the bottom line called dropped frames.

Maybe it will be useful for you, here is some info about Youtube's codecs -> https://github.com/rg3/youtube-dl/blob/master/youtube_dl/extractor/youtube.py#L411-L417
And it seems the only difference between the ids 136 and 298 was the framerate.

> awesomed
Not sure if you're serious or not, I added a small indication on the picture below where you can see the drop details in our screenshots. Shows dropped / total.

Deleted: wY33dfo.jpg 284 KB

	wY33dfo.jpg 284 KB View Download

Sorry! I was serious haha
And oh! Huh, i guess i was looking for realtime fps count 

> It even stops to buffer, and I'm on a fiber line that's not being used.

That sounds unrelated. This bug was tracking frame drops in full-screen mode.

> Some frames are still dropped (about 1.3%) and the fact that the "context menu trick" still works...

Hmmm. So, better, but not fully fixed. What are the results like with the workaround in place? Is it smoother then? I assume it is since that should be equivalent to the context menu trick.

> The issue is not resolved for me as well. It works without any problems in Edge and Firefox.

Commenter #131, it's not clear if you are seeing the same issue. This particular bug only happened when displaying full-screen video using direct composition. If you're seeing similar results in windowed mode then that must be a different issue.

> Hmmm. So, better, but not fully fixed. What are the results like with the workaround in place? Is it smoother then? I assume it is since that should be equivalent to the context menu trick.

I compared once more with and without the workaround and the difference between  them is so small (both ranging from 0.3% to 1% DF out of 10 000 frames) that it may well be due to network conditions. Since I'm too lazy to run hundred of tests to check the significance, I'd call this MS update a "fix". =)

Dear commenter of my comment N131, I've checked it again and can't see any drops in 30fps videos with or without the direct composition, but right after that KB4074588 patch, I still had these 3 seconds drops with composition in fullscreen. Right now, as I said, it skips 1-3 frames every 5 seconds in videos with 60fps.
If you consider my issue as unrelated, well, then let's call this bug `fixed`.

Thanks for double checking. We appreciate your patience and assistance in helping us deal with this issue. I'll leave it up to the bug owner as to whether they want to remove the workaround at some point in the future.

Well, I've tracked my issue down to having a cloned display. I have a tv plugged in, so I can sit back in the lounge to watch stuff. Guess I'll just be extending the desktop.

Instead of having about 1/3 of my frames dropped, it's like at 50 frames out of thousands now. (I have a video on still testing, currently at 5/2813 dropped frames)
Firefox still has 0 dropped frames, but I have a lot more going on in chrome, so I can understand that at least.

Keep in mind not all browsers report dropped frames equally. In past testing using HDMI capture we've found Chrome to be the most accurate reporter, with other browsers failing to report up to half of the drop frames.

True, but considering it reported no loss for a video (it was an actual 0), I'm inclined to think it did fairly well. But then I do have to rely on what it reported.

Also have this issue. Would like to note it's not only old NVIDIA cards. My specs below.

Problem: frame rate issue in full screen, audio sync problems.
Attempted fix: disable hardware acceleration
Outcome: frame rate issue and audio sync issue fixed on youtube, not on all sites. Now there is a kind of tearing. Playing video in full screen, I get rectangles popping in the video for a fraction of a second. These are the same size and position as paused video frames in windows behind the current window. (not sure if tearing is the right word for that) If I minimize all windows except the current video in full screen, the rectangles stop popping.

Specs
Microsoft Windows 10 Enterprise 2016 LTSB Version 10.0.14393 Build 14393
Chrome Version 66.0.3359.139 (Official Build) (64-bit)
Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
EVGA FTW2 GeForce GTX1070 8GB GDDR5
2x8GB Crucial DDR4 2133 CL15
Samsung 960 Evo 250GB M.2 NVMe
ASRock Z270 Gaming K6
D-Link DWA-582 Dual Band AC1200 PCIe Wireless
Fiber speed test: 100Mbps down and 3ms to nearest exchange

DxDiag and chrome://gpu outputs attached.

If all that can't run full screen video 1080 at 60 fps, something is going horribly wrong ha. Also have 3 HDD partitions and 1 BitLocker partition but Chrome is running off the NVMe drive.

Have I missed anything relevant? I have my msinfo32 entire dump handy, but not sure if that may have personal info since there are logs included.

Deleted: chrome--gpu.txt 8.1 KB

chrome--gpu.txt 8.1 KB View Download

Ah apparently I didn't attach properly. DxDiag output attached this time.

Deleted: DxDiag.txt 76.1 KB

DxDiag.txt 76.1 KB View Download

Has it been fixed in Chrome 72.0.3585.0 (Official Build) canary (64-bit) (cohort: Clang-64)?

Don't seem to be dropping frames in my usual test without having '--disable-direct-composition' enabled, same test on 70.0.3538.67 (Official Build) (64-bit) (cohort: 70_67_Win) still drops frames constantly.


Using nvdia drivers 411.63.

We disabled direct composition unless your device supports hardware
overlays (generally supported only on newer Intel laptops).