Probably for the better. There can be a ton of compatibility problems, the simpler solution is to go smack some sense into developers like Unity to start using modern graphics APIs.
Unity now supports Flip Model, but it’s not enabled by default and they don’t explain to developers using their engine why they should enable it.
Honestly the only games i seen use flip mode is DX12/UWP titles, even vulkan in those games i played that has it had problems with DWM related stutter in multi monitor scenarios, you don’t even need a monitor with a different refresh rate, as i have DWM related stutters with only 60hz + 60hz setup.
MS really needs to force developers to use it…
I’m still not sure exactly what that issue is, despite having seen people talk of it over multiple years now…
Only stutter-related issue I experience is when Nvidia’s drivers decides that the secondary monitor (regardless of refresh rate) should follow the same refresh rate of the primary G-Sync enabled monitor.
It even does this with the secondary monitor being a non-G-Sync monitor – if the primary monitor runs at 3 FPS/Hz, then the second monitor will also only update the image on the display at 3 Hz.
I’m pretty sure that has nothing to do with NVIDIA. The only way the DWM can draw at two different rates is if the software it is composing has that new Tearing flag enabled. That allows the DWM to change its internal composition rate.
Wasn’t there a problem with Hardware Accelerated GPU Scheduling and multiple displays too unless that’s been fixed?
NVIDIA has it supported now but AMD’s taking their time implementing it outside of a by this point a very outdated branch of the May 2020 driver release. (20.5.1 with GPU scheduling support.)
Latest updates for 20H1 and 20H2 I think also improved refresh rate variance across multiple displays and how that’s handled but I’m not 100% on how VRR or G or Free sync manages with this maybe more so with the varying panels and firmware updates here like some flickering issue with the Samsung Odyssey and I think one of LG’s recent models had a upcoming Ampere GPU compatibility firmware fix which might be out by now.
That flag have seemingly almost always been enforced with G-Sync enabled in most games I’ve tested (in only a few were the flag not already applied on the swapchain), and it have had no effect on the issue for me… 
That’s because Microsoft describes that flag completely wrong.
It’s not about tearing in a single application, it’s about the DWM being able to invalidate the results of other windows to meet changes in rate of the foreground window.
Normally, all applications are competing for a place in the DWM compositor’s flip queue and they all have to be composed at the same rate. Tearing lets the DWM adjust its composition rate to match the foreground window.
BTW…
https://www.pcgamingwiki.com/wiki/Glossary:Frame_rate_(FPS)#Frame_rate_capping
That claim about RTSS adding the least delay needs citation.
I’ve been looking over the numbers w/ RTSS for over a month now and even the earliest iteration of my framerate limiter before I started tuning things for latency was outperforming RTSS by good margins. The updated limiter is to the point where it’s not adding latency, but actually removing it versus all known implementions (driver, in-game, third-party tool).
It’s pretty irrefutable if you look at this:
RTSS adds a ton of latency and SK runs circles around it.
I honestly don’t know what the problem with Windows DWM is.
Having only 1 60hz monitor connected, everything is fine in both full-screen, and borderless with borderless having smidge more stuttering but immediately when I connect another 60hz monitor, I get constant stutter in borderless, real full-screen is still smooth in this case, mixed refresh rate is even worse, it really seems like only the primary designated monitor is able to have completely smooth frame-times
Don’t know if this is suitable
I’ve saved my edit, but i don’t know if some moderator will just reverse it.
I feel like that needs citation too 
I’m all but certain it is a true statement, but those kinds of claims with nothing to back them up are not really applicable in a site that’s supposed to be giving information rather than (at best) educated opinion.
I’ve removed the SK line. I guess as long as the RTSS claim is removed, should be fine?
Yeah, I think that’s fine. I hate that I have been basically disproving claims about RTSS for the past month, it probably sounds like I have something against the software. There is just a lot of misinformation about its performance and it begins with statements like used to be in that Wiki article.
Hmm, i wouldn’t worry about arguing over it any further. If DF cover the tool, then their evidence will be irrefutable.
lol,
“Amazon’s Terrible Choice”
Just curious but to get the lowest amount of input lag without stutters do I use the VBLANK option?
I see that it says it needs VERY stable framerates, but what about games with FPS issues, also what about vsync setting in NVCP?
Hahaha, I love LockPickingLawyer, his style of genuinely fun to watch videos that take only a minute of your day should be used by more tubers out there.
Any of you folks managed to get an Ampère card in the midst of all of this launch confusion? Been a hectic few days here on my end, but managed to secure me an ASUS TUF RTX 3090, those are being regarded as some of the better quality 30 series cards so far (yet not amongst the most expensive - though yeah, being Brazilian that did set me back some $2,300 still) models, should arrive sometime over the next few weeks.
It’s because those claims traces their origin back years ago, during an entirely different time. Wiki editing as a whole have an issue with outdated statements in an ever-changing environment. We typically don’t enforce references as much on our glossary pages as otherwise it’s usually set in stone, but yes, where applicable they should be provided as often as possible.
That’s going to cause stutter. Waiting for VBLANK can lower latency, but you should only use it for that purpose if you have an extremely high framerate without limiting (i.e. CS Go).
Hmm the reported latency with Presentmon doesn’t seem to move from no frame limiter to SK limiter unless i enable VBLANK, with VBLANK disabled presentmon reports the same latency as framelimiter disabled
