+++ This bug was initially created as a clone of Bug #1127151 +++ See https://bugzilla.mozilla.org/show_bug.cgi?id=1127151#c47 and https://code.google.com/p/chromium/issues/detail?id=467617 It might be worthwhile to use D3DKMTWaitForVerticalBlankEvent[1] instead of DwmComposition since we could support Vista and from the chrome bug, it looks like it's more accurate than Dwm. A sample implementation is at [2]. This bug is to investigate replacing the current DwmFlush approach in the Windows vsync thread with D3DKMTWaitForVerticalBlankEvent. [1] https://msdn.microsoft.com/en-us/library/windows/hardware/ff547265%28v=vs.85%29.aspx [2] https://gist.github.com/anonymous/4397e4909c524c939bee

I tried using this today due to bug 1147953. However, on Windows 10, the header required for this function, D3dkmthk.h, doesn't seem to exist in Visual Studio. Upon further investigation, these functions are reserved for Client drivers, not really client applications. Reading the docs some more (https://msdn.microsoft.com/en-us/library/windows/hardware/ff568609%28v=vs.85%29.aspx), it looks like this calls into the kernel and are mainly supposed to be used by drivers. It's also quit explicit that the header file is reserved for device driver interfaces (https://msdn.microsoft.com/en-us/library/windows/hardware/hh855133%28v=vs.85%29.aspx). I'm don't think we want to have Firefox pretend to be a driver unless I'm mis-reading these APIs. I'd rather not poke into gdi32.dll and explicitly call these functions that are reserved for drivers, so closing as WONTFIX.

Makes sense. FWIW, there is actually some precedence for using functions from d3dkmthk.h: bug 689870. In that case there was no alternative though.