New version causes display lag

[George3011]

Been using the software for ages, but ever since the 2.0 update there has been extreme display lag when the window is open. I've never seen anything like it before really.

With the window visibly open or closed, the top of my display gets lighter and the refresh rate dips from 100hz to 30-40hz. It happens when moving the window around, hovering my mouse over it, moving my mouse around with the window open/in the taskbar, etc.

Very weird, downgrading to the last stable version pre-2.0 (Version 1.7.28).

[Tiberiusmoon]

I have noticed this aswell

[Ryochan7]

Is your graphics card or chipset not strong enough for 2D graphics rendering using Direct3D? Can you use normal Desktop Compositing effects within Windows? WPF utilizes Direct3D for rendering graphics that are displayed in the window. If your computer cannot preform hardware 2D acceleration then it might revert to using software rendering which could be slow; I believe that Qt Quick displays warnings if it has to revert to software rendering but that toolkit uses OpenGL rather than Direct3D.

I can run DS4Windows 2.x in a VirtualBox VM with no problems. I would assume that people running the program on modest computers would be able to handle the graphic requirements of WPF with no problems.

[George3011]

I think my GPU is more than adequate (OC'ed GTX 980ti running a 3440x1440 screen at 100hz). Moreover, I've tried disabling/enabling full-screen optimisations in the Compatibility panel of the .exe. Again, nothing like this has ever happened with any program but it seems to be endemic to Version 2.0 of DS4Windows onward. 1.7.28 works just fine.

[Tiberiusmoon]

Gtx 1080Ti with i7 6700k 32gb ram @2999Mhz for me.

Edit: Task manager shows low resource usage all round

[Ryochan7]

You two have far beefier GPUs than I do. Mine is a GeForce GTX 5500 Ti. It is old enough to not support Vulkan. On my machine, the WPF version of DS4Windows is more responsive than the Windows Forms versions have ever been. Another question if you two are running Windows 10. Can you run UWP applications fine?

Please let me know if you can isolate the problem so I can find a way to work around the problem. There isn't really anything that I can do at this point. Reverting the code back to using Windows Forms is not an option.

[Tiberiusmoon]

the ufo test and YT detects stuttering too but not as bad as DS4

[mika-n]

Are you using any GPU overclocking apps in the background (those may do some d3d injections)? Try closing those. Is the color theme of a desktop set to use "transparent color" style? Any difference if color theme is non-transparent (Transparency Effect option in Settings/Personalization/Colours)? The same slowness right after reboot? The same slowness with and without gamepad connected?

Here the new WPF GUI works faster than the old WinForms in my development machine (laptop with IntelHD integrated GPU), so very strange that any GeForce would struggle to render WPF window elements.

[Tiberiusmoon]

still stuttering by the following: restart disabled MSI afterburner disconnected controller

Noticed something: if the DS4 and the webbrowser running YT are on seperate monitors, there is no stutter

[cascardian]

Sounds like you're having some sort of issue with performance states being stuck. I vaguely remember experiencing something similar with NVIDIA Inspector's MDPS function and/or Afterburner's voltage curve editing, which you can lock to a p-state via hotkey if I recall correctly. You can also force applications to use a higher p-state via MDPS if you want to try that. Anyway, check you're all clear on being on defaults (prior to closing these programs) to test this. Close RTSS, too, by the way, or create a DS4Windows profile and set the application detection level to none.

Other than that, you might try a separate profile for DS4Windows in the NV Control Panel with the Prefer maximum performance setting applied or going from Optimal power to Adaptive (maybe try that with the global profile as well).

Also, does GPU-Z show your PCI-E bus interface properly switching from 1.1 to 3.0 on load (click on the question mark and start the render test)?

[Corrodias]

Are you folks using G-Sync? Try temporarily disabling it entirely; see if that alleviates the problem.

[aj0413]

Been experiencing this issue, as well. Been driving me nuts. The problem is replicable with windows Sticky Notes, as well.

I use a PG348Q and it has a built in FPS counter, so I can visibly see the stutter numerically without running anything else.

I have a 3900x and 2080ti w/ 32Gb RAM, so it's not a resource issue

Seems to happen when context switches to the problematic program (ie. DS4Windows or Sticky Notes), by clicking into it. The largest stutter can be replicated by clicking into one of the problem programs and then moving the mouse outside its window to somewhere else on the display

Disabling G-SYNC does seem to make the issue go away with both programs. WIll try a few more things.

EDIT:

Seems disabling g-sync for the specific programs is the best solution for now.

Thanks @Corrodias -> Any insight in why this is athing?

Also, @Ryochan7 -> Given you're stated setup, it's understandable how this might miss you.

[Ryochan7]

I guess it can sometimes be handy to not be using the latest tech. I looked at the Sticky Notes app. I am pretty sure that it is a UWP app looking at some of its dependencies. It works perfectly fine on my system.

At least this confirms that modern UWP apps can be susceptible to the same problem. Nothing is inherently wrong with how DS4Windows is set up. I wonder if this type of issue would affect other frameworks as well; I would be curious if this issue also affects Qt Quick apps although that uses OpenGL rather than Direct3D.

[Corrodias]

There are 2 modes that G-Sync can run in: it can be only for fullscreen programs (and those running the DXGI flip model or DirectX 12 when nothing else is drawing on the same display), or it can be for fullscreen and windowed programs, but the way windowed program support is implemented is a little janky. If you enable the windowed program support, the driver sort of hacks the desktop compositor (DWM) and does some magic beyond my ken to go around DWM and try to provide this display sync. Normally, DWM handles all of the vsync for windowed programs.

So, what I wonder is, what about windows that don't draw frequently? What's it syncing to? And my guess is that in some cases, the driver makes a mistake and thinks that a windowed program like DS4Windows is requesting vsync but is only able to draw infrequently, giving it what appears to be a low framerate. And due to the way G-Sync works, if the program that currently has sync focus is delivering frames at a low rate, it basically turns the entire desktop into an unsynchronized, stuttering mess.

I figured G-Sync might be responsible for the issue you described because the symptoms exactly match what happens to the system during video game loading screens that run at very low framerates.

If you had G-Sync set to work for both fullscreen and windowed programs, try it set to just support fullscreen ones.

Trivia: Most people are under the impression that windowed G-Sync doesn't work at all in Windows 10 past a certain Nvidia driver. In my experience, that's not entirely accurate, but you do have to be operating under certain conditions which include no other programs besides the target program using GPU acceleration, which means your browser has to have it disabled or have no videos open in any tabs, that sort of thing. It's tricky to get working. You're better off using games in fullscreen or forcing them to use DXGI flip with Special K.

[Ryochan7]

Looking at this issue a little more, I have found a couple of ways to potentially work around this. The UI thread only refreshes the window when any control is updated and marked as dirty so that would explain the low framerate when using G-Sync; it is a known issue with running WPF applications when G-Sync is enabled. Listening to the CompositionTarget.Rendering event allows an application to update the UI thread along with the Composition Thread even when no UI elements have updated.

There is also a way to force software rendering in WPF. I have not tried that yet but I am curious how the app would perform.

[Ryochan7]

I need to test it a bit more but I kind of like the performance when using the RenderMode.SoftwareOnly option. I could see myself enabling that option by default.

[Ryochan7]

Please try out version 2.0.10. Software rendering mode is enabled by default so that should make sure G-Sync does not interfere. I personally like the app performance when using software rendering slightly better than when using hardware acceleration. The GUI feels a bit snappier now and input reader performance is better. None of the other WPF apps that I use on a regular basis use software rendering by default so this is new territory for me.