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.

[ghost]

@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.

[Tetedeiench]

Spotify also ran into this : https://community.spotify.com/t5/Desktop-Windows/Low-Frame-Rate-with-Desktop-App/td-p/4617800/page/2 (and many others)

The best solution is WPF not locking its frame rate and leave it at the user selected value (animations can be at whatever fps they want, they leave the refresh rate unlocked)

Just like about every 3D game out there : a game can run at 40fps with a monitor refresh rate applied set at 120Hz. I wonder why a spinner in WPF couldn't do the same.

We could argue Nvidia and AMD could leave desktop app out of their VRR feature, but this seems like fixing the problem on the wrong end of things.

The sad part is that if your app requires a full framework to function (like mine, I want my app to be fully portable without installing some framework beforehand, so I basically target full framework right now), you're left sorry.

[rubenalamina]

I finally found a way to alleviate this by using a profile in Nvidia's Control Panel. Previous attempts of setting a profile for the executable with Monitor Technology set to Fixed Refresh didn't work but after trial and error, I found a combination that finally does:

• Monitor Technology: Fixed Refresh
• Max Refresh Rate: 60 FPS
• Preferred Refresh Rate: Highest Available
• Vertical Sync: Let the 3D Application Decide

The last one is changed automatically. Gsync recommended configuration is to run Vertical Sync On or let the Application Decide. For games, using it at On is desired to not have to change it on every game but Nvidia's control is changing it for the profile after you change one of the other 3 settings so I let it do that and tested several programs.

No problems so far on programs like Windows Terminal, Affinity Photo/Designer, even the Windows Feedback Hub and the Xbox App had this issue on my system. With a profile for each executable with the settings above, there's no frame drops when those programs are in focus.

Having said all that, this is a workaround that is not documented anywhere and is still an issue that should be addressed by either Microsoft, Nvidia, AMD or all of them. VRR usage will just keep increasing as time goes on.

[lindexi]

See:

wpf/src/Microsoft.DotNet.Wpf/src/WpfGfx/core/uce/rendertargetmanager.cpp

Lines 669 to 683 in 6be750a

	HRESULT
	CRenderTargetManager::WaitToPresent(
	__inout_ecount(1) UINT *puiRefreshRate,
	__out_ecount(1) MilPresentationResults::Enum *pePresentationResults,
	__inout_ecount(1) QPC_TIME *pqpcPresentationTime
	)
	{
	HRESULT hr = S_OK;
	//
	// By default We don't support waiting for VSync. Simply notify the listeners
	// that we couldn't wait for VSync and let them choose what to do.
	//
	*pePresentationResults = MilPresentationResults::VSyncUnsupported;
	*puiRefreshRate = 60;

*puiRefreshRate = 60;

[Symbai]

On one monitor with G-Sync I've noticed instant crashes when G-Sync was set from fullscreen to fullscreen + desktop applications, no matter which WPF app I've ran. Other users with G-Sync reported a GPU usage from 20-70% on a simple WPF application. I don't know why @ryalanms added ".NET Framework" tag because this problem also appears on .NET 3.1 -> .NET 6

Now that G-Sync and VRR and Freesync become more popular this is a serious issue as we developers have no control, there is no workaround nothing. And for the end user its not obvious whats the reason. Moreover this affects ALL WPF apps out there.

[AlienFreek]

Currently experiencing this issue with a .net 6 app I'm developing.
The issue seems to appear on any VRR monitor even if the app is contained entirely on a separate, non-VRR monitor (only tested with G-SYNC), even when G-SYNC is enabled for full screen only (app is non-full-screen). However, the issue appears only when a fullscreen application is running on the VRR-enabled monitor (in this case a game) and doesn't appear when utilizing the desktop.

[bugproof]

144hz monitor here,
created basic wpf app in .net 6
looks very bad when dragging the window

[lindexi]

@bugproof How about dragging the other win32 window, such as explorer?

[NewUserHa]

this issue buggy PowerToys too. microsoft/PowerToys#11810

How about dragging the other win32 window, such as explorer?

@lindexi dragging any other app doesn't have any issue at all.

*puiRefreshRate = 60;

@lindexi the app may should use max fresh rate instead of 60 which may looks laggy on 144hz monitor I guess

I remember task manager probably shows that the powertoys one seems to have GPU engine usage(probably GPU - 3D?). but it should like any other app without any GPU usage unless users ask it to

[adammarks]

@ryalanms We have many mutual customers that are being affected by this issue with a major uptick in recent months, we think customers are upgrading to high-refresh monitors that have VRR and are now being affected by this issue.

We are on WPF with .NET framework, so mainly interested in fixes for .NET framework or any workarounds that we could do in our code for this problem.

[NewUserHa]

the 'visual studio installer` is affected too

[elexor]

How many years are going to go by without a fix to this major issue? give us a way to at least disable vrr for our applications.

[lindexi]

@elexor It's hard for me to test because I don't have the VRR device, so it's hard for me to help you. Could you change the puiRefreshRate to a bigger number and then build the private version to test?

[elexor]

I'm not exactly sure how to compile and setup wpf. If I can figure it out, I will try.

[Symbai]

@lindexi Why don't you just compile and upload binaries here so everyone with VRR display can test it? I think it would be more useful to get feedback from several VRR users instead of having this tested by only one.

[lindexi]

@Symbai Thank you. Good idea.

[Mgamerz]

This setting pretty much kills my app at 144hz - it depends on a lot of dragging and dropping, and it makes me think the app is always on the verge of a crash. It would be nice if I didn't have to give up 144hz to have a functional application.

[milos12345]

This should be prioritized and fixed, including for .NET framework, as at this point it makes current WPF software unusable and and hard to justify maintaining existing software, while also making any future WPF development out of consideration with more users getting advanced displays like these.

[bugproof]

This should be prioritized and fixed, including for .NET framework, as at this point it makes current WPF software unusable and and hard to justify maintaining existing software, while also making any future WPF development out of consideration with more users getting advanced displays like these.

WPF has no future. It's legacy, over-complicated tech. Web-like component frameworks you can style with CSS won. If I ever want to consider making new desktop app it's not going to be WPF. It's a miracle it's still being developed.

[milos12345]

This should be prioritized and fixed, including for .NET framework, as at this point it makes current WPF software unusable and and hard to justify maintaining existing software, while also making any future WPF development out of consideration with more users getting advanced displays like these.

WPF has no future. It's legacy, over-complicated tech. Web-like component frameworks you can style with CSS won. If I ever want to consider making new desktop app it's not going to be WPF. It's a miracle it's still being developed.

This is WPF-specific repo and a specific issue page. Please leave unsolicited advice, unrelated random opinions and pushing personal agendas for Twitter.

[MarkIngramUK]

I'm using a .NET 6.0 app, and suffer from mouse movement and UI lagginess when G-Sync is enabled. I have to fully disable the option, I can't even have the Full Screen only option enabled. I'm using an Nvidia 2080 RTX SUPER with ASUS ROG Swift PG27U.

[Aemony]

I'm using a .NET 6.0 app, and suffer from mouse movement and UI lagginess when G-Sync is enabled. I have to fully disable the option, I can't even have the Full Screen only option enabled. I'm using an Nvidia 2080 RTX SUPER with ASUS ROG Swift PG27U.

This would suggest the UI app it happens with is triggering Windows modern MPO optimizations, as that allows VRR to engage for windowed applications, as if they were running in fullscreen. That approach is basically the replacement for Nvidia's Enable for windowed and full screen mode option.

As it stands right now developers would have to make use of the NVAPI to disable G-Sync for their apps, or try to reach out to Nvidia and get their apps blacklisted from G-Sync (something I myself have been unsuccessful in doing so far). I am not aware of a method that would work for AMD or even Intel users, as those don't have the same sort of VRR/driver controls like Nvidia has with their NVAPI.

[sipso]

Is there any work being done on this issue?

[lindexi]

@sipso Sorry no. Could you change the *puiRefreshRate to a larger value, see #2294 (comment)

[sipso]

@sipso Sorry no. Could you change the *puiRefreshRate to a larger value, see #2294 (comment)

I'm not a dev, i use an, or rather would like to use, an app that uses WPF. Is this a simple config file edit?

Why isn't this being worked on?

[Mgamerz]

I'd love to see this get implemented. I get tired of users saying my app is super laggy.

…

On Tue, Nov 19, 2024, 12:11 AM sipso ***@***.***> wrote: @sipso <https://github.com/sipso> Sorry no. Could you change the *puiRefreshRate to a larger value, see #2294 (comment) <#2294 (comment)> I'm not a dev, i use an, or rather would like to use, an app that uses WPF. Is this a simple config file edit? Why isn't this being worked on? — Reply to this email directly, view it on GitHub <#2294 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAU4VFCEXE3NO2WRW4A43MD2BLQD5AVCNFSM6AAAAABSATHJ2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBUHA3DEOJRGY> . You are receiving this because you commented.Message ID: ***@***.***>