Laggy user experience when using VRR display

[JosefNemec]

• .NET Core Version 3.1
• Windows version: 1903
• Does the bug reproduce also in WPF for .NET Framework 4.8?: Yes

Problem description:

When using display with variable refresh rate (I only tested it on G-Sync one, but my guess is that the issue will occur on FreeSync too due to the nature of this behavior) the general user experience is not smooth and feels very unresponsive. The issue is that WPF (being DirectX application) is picked up by the display driver and display refresh is adjusted based on framerate output of WPF. However since WPF's framerate is usually bellow 60, this has a big impact on general responsiveness of the interface because even things like moving mouse will be noticeable stuttery. More so if user has display with high refresh rate (like 144Hz), the switch to and from WPF application can be quite jarring.

Expected behavior:

WPF's framerate is not picked up by the graphics driver and refresh rate stays static when using said app. For example I didn't notice this being an issue with UWP or other desktop applications with accelerated GPU rendering.

I understand that technically this is working as intended, but in my opinion it doesn't make much sense for WPF application to be VRR compatible, given the type of applications that are generally created with it. I think it would make more sense to have VRR compatibly turned off by default, but have an option to enable old behavior if possible.

I think this shouldn't be taken lightly since VRR display use is on rise and it's become de facto standard in gaming related PCs (I develop gaming related app and quite a few users noticed this issue).

Minimal repro:

This simple example can be used to reproduce the behavior. Just moving mouse over list box items will force display to render at about 30 fps.

<Window x:Class="WpfApp1.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Height="450" Width="800">
    <Grid>
        <ListBox>
            <ListBoxItem>test</ListBoxItem>
            <ListBoxItem>test</ListBoxItem>
            <ListBoxItem>test</ListBoxItem>
        </ListBox>
    </Grid>
</Window>

[arpitmathur]

@JosefNemec Thanks for bringing this up. We will take this into account for our .Net 5.0 planning process.

@arpitmathur Are there any workarounds for this?

[grandsilence]

@arpitmathur any news?

[grandsilence]

A temporary solution is change adaptive sync mode in Nvidia Control Panel from windows + fullscreen to full screen only mode

[s-rog]

This also breaks VRR when using a WPF rendered overlay while in a game or video playback with VRR.

Edit: which also includes built in overlays like the volume hud

[d4g]

Is there any update on this issue?

[ryan-haver]

I assume with the long list of open issues, this likely won't see a resolution any time soon. It would be nice to be able to use VRR without needing to force fullscreen exclusively, although setting fullscreen only mode doesn't seem to solve my issues completely.

[Tetedeiench]

Any update on that issue ? I am affected by this. If anyone know of a workaround that doesn't mean fiddling manually with Nvidia driver settings, I'm interested, I haven't found any.

[laurentksh]

@arpitmathur any news on this ? Quite ridiculous this issue exists to begin with.

[jmonachesi]

Since you won't fix this, probably because it's a DirectX issue, we just need either a way to invalidate the screen at 60/120/144 fps or a way to add an exclusion from VRR/FreeSync/GSync features.

For instance if we could know how to add into the registry the exclusion an installer could deal with this issue. The first option would be to create a control that would automatically invalidate itself after being painted.

[rubenalamina]

This is a big issue and will only get worse as more PC users start using VRR/Gsync/Freesync monitors in their setups. I've been suffering from this issue in a few notable programs like Affinity Photo, Affinity Designer, SafeInCloud, even Windows Terminal has this issue but they have an option to use software rendering to helps as a workaround at least.

I'm actually surprised that this problem has not been more prominent given many in the .NET dev team and contributors should be using VRR displays and probably already ran into this problem with some programs.