Kill dwm.exe on Windows for less input lag and better performance
github.com
github.com
> 2 years ago
> It [sic] tested it on Windows 10 LTSB (1607)
If you want to reduce input lag for exclusive fullscreen, turn off “fullscreen optimizations”. But that specific bug, introduced in build 1903, was fixed a few years ago. (But if you still somehow get it — you can just turn this off per-game instead of this wide hack!)
Modern DXGI flip presentation model doesn’t add input lag anymore and properly detects when the exclusive fullscreen app is the only one showing, and gives it direct render control. (E.g. you can frame tear again!)
I think some UIs will also just not work nowadays if you kill DWM, even more likely in Windows 11 since more UI got moved to WinUI.
As an extra note, Windows 11 ships with a feature to force the DXGI flip presentation model in older games.
"Gamers" can be like audiophiles in the way the spread half-truths and even outright misinformation. The number of people I still see thinking you should turn G-Sync off is downright silly.
For everyone else, you'd really want to prove it with a high-speed camera or something.
nothing is worse though than a rhythm game that can't keep proper rhythm itself.
Hrmmm. I’m not sure this sentence even makes sense. I’m not sure what the definition of 0ms input lag even is. And I say this as someone who has deeply profiled true end-to-end input/output systems. 0ms relative to what exactly?
If you spend 20 minutes getting used to something you could maybe tell the difference if 3ms of input lag was artificially injected. Maybe. But that’s an exceedingly small value and if I had a toggle switch that turned it on/off I’d bet against you being able to tell when it’s on.
It does depend on the context. In a game like Guitar Hero 3ms is going to be exceedingly difficult to distinguish imho.
At the same time, sure, we easily compensate.
This is a deep and interesting enough topic that you could publish a pretty good and valuable paper on what the JND is for poor, average, elite, and “professional” players is.
If the line is 3ms for pro I will gladly bet the over!
The total lag is almost certainly an order of magnitude above.
". In general, human speech is jammed by giving back to the speakers their own utterances at a delay of a few hundred milliseconds. "
Edit: I can also tune a guitar by plucking two strings at once, but I can't by plucking them one at a time.
This really has nothing to do with noticing the absence or presence of a 3ms latency difference in a situation where your baseline is already dozens of ms of latency in the best case.
3ms is how long it takes sound to travel a meter.
Do you notice the difference in audio/video sync between sitting in the front or the back of the cinema?
rhythm games are literally scoring your timings, a cinema offers no such equivalent of a scored feedback loop.
No, I wouldn't notice 3ms on the lips of an actor. Drummers are known to be able to perceive 1-3ms differences in timing; again, a tactile action.
If a human is involved in the action their sense of rhythm and prediction takes over to allow for manipulation within those timescales. It's not uncommon, either.
You are claiming that someone can tell the difference between playing the game oneeter or two metres from the speakers.
Put another way, on a large stage the sound from the bands monitors takes ~10ms to reach the drummer.
I don't have data, and neither does anyone else here apparently, but in the absence of evidence it seems exceedingly likely that any perceived differences due to 3ms latency (difference ?) are placebo. We know that placebo is real and large so unless someone has an experiment that tries to account for this (e.g. properly blinded) my prior is that you can't tell when playing a rythm game whether the speaker is 1m or 2m from you.
Like tuning strings by hearing when you can pluck both strings at the same time, vs doing it using absolute pitch.
I don't think we could tell direction based on the distance and less than 1ms difference alone.
Going on sort of a tangent, but since it was mentioned: I hate variable refresh rate.
I suppose my eyes are just sensitive to changes in rendering speed, because I tried it and I couldn't stand the variable ghosting. For me it's worse than screen tearing, which for me is perfectly resolved with vertical syncing or just capping the frame rate to something less than my monitor's refresh rate.
It can be a bit of a curse. LED headlights and taillights give me headaches. A lot of LED street lighting and business lighting hurts me. Etc.
I used to be basically unable to stand a CRT under ~85hz. :(
You could probably fix it by capping your game's framerate to whatever it can maintain consistently within your monitor's VRR window. This would give you a smooth consistent experience, without screen tearing or vsync-induced lag. Since it's not working in a fixed refresh rate container, you can do more unconventional numbers too. I like to run a lot of games at 90 FPS.
First off, I almost never get screen tearing. The only times I get screen tearing is if a program renders faster than my monitor can refresh, and my monitor (a Dell S2522HG) refreshes at 240Hz; screen tearing simply isn't happening. As for input lag, if there is any it's insignificant enough that I don't care.
Second of all, my problem is with the the way variable refresh rate works and not with anything on the software side or the monitor itself. Variable refresh rate is exactly what it says on the tin, the refresh rate varies.
My problem is because the refresh rate varies, the difference in refresh rate becomes very distracting. One moment my monitor is at 240Hz, the next at 135Hz, then 170Hz, then 70Hz, then 200Hz, and so on for an exaggerated example. Anything that's moving (eg: my mouse cursor) leaves more ghosts the lower the refresh rate becomes, and vice versa. This is very distracting because it's not consistent.
Imagine you're listening to music, and the pitch goes up and down arbitrarily. You will probably agree that it's distracting, and that's basically what I find variable refresh rate to be. It is distracting to a fault, and I would rather deal with my monitor going at full speed and limiting my software as appropriate to prevent tearing for a consistent experience that isn't distracting.
I have a VRR monitor, but I limit it to 120Hz specifically for that reason. Most of the time it just sits there. The exception is while gaming, where sticking to 120 was never an option; I find the variation less of a bother than the more dramatic shifts down to 60/30 would be without VRR.
My suggested fix should still solve your other problem, which is the wild swings in framerate. Bouncing between 200 is 100 certainly is jarring, and capping your game's framerate to make those swings smaller or nonexistent will fix it.
If I had a dime for every time people were being told to manually manage their Windows page file "for performance"...
A page file is, as it says, a file that's located in the root of whichever partitions that they are configured on. By default it's only configured on the C: partition and the size of the page file is variable, managed by Windows according to system demands. The page file is equivalent to a swap partition, for the Linux and BSD users out there.
Manually configuring the page file has a number of benefits, if you know what you're after (and you're using HDDs):
* You can specify a size, fixed or variable, for your page files. By default Windows allocates a fairly small page file, and if your page file use exceeds that allocation Windows has to allocate more space on the fly. This takes time, especially if the page file resides on a HDD. If you configure a fixed size, or a variable size with a large minimum size, you don't need to worry about that dynamic allocation which translates to more performance. Another benefit to a fixed page file is that you can have the page file occupy one continuous area on a HDD platter, for better access times and thus better performance; a dynamic allocation more often than not leads to a fragmented page file and thus worse performance.
* You can specify which partitions you want to use for your swap space. It wasn't unusual to just dedicate a partition to a page file, effectively the same thing as a swap partition, especially if your C: partition wasn't that big. This is important for the next bullet point.
* Back when we still ran our programs off of HDDs, making a partition earlier in the drive meant locating that partition on the outer areas of the platter. The outer areas of the platter travel faster than the inner areas, because physics, and faster platter speed means faster access times. By placing the page file on such a partition, the page file has better access times and thus you get better performance.
A lot of these benefits have gone away thanks to RAM becoming both cheaper and more plentiful, and the storage medium where the page file resides changing from HDDs to SSDs in general. So most people usually don't need to mess with their page files anymore.
But for people with specific needs or just a desire to really fine tune their systems, tweaking the page file by hand is still a worthwhile endeavour if you understand what you can get out of it.
* The NT kernel does not overcommit; and
* As a closed-source OS, client and server editions of Windows do not use build configurations targeting embedded systems; they essentially require ample swap space. They won't run well if users attempt to forcibly minimize or disable their page file.
It's about ethics in game journalism!
I have a Freesync display and a compatible GPU and i can feel the difference between no vsync and freesync. There is a slight lag there, if you cannot feel it do not assume that others cannot too (some people even seem to not be able to feel a difference between having vsync on and off or having a compositor or not enable - nowadays really only possible on Linux but in the past you could also do it with WinVista/Win7 and in Win8 with hacks like the one linked - which is mind boggling to me).
Of course the input lag depends on the game and how you play it. First person games with raw input, 1:1 mapping of the input (i.e. no filtering whatsoever) and little to no frame queuing (some engines run 1-2 frames "behind" the game state and if you add things like triple buffering you end up with extra lag) are the best to notice this whereas third person games played with a gamepad (where you have only indirect control of the camera - you control the camera's rotation speed, not the camera directly) are way harder to notice, as are games where you mainly use the mouse to click where to go (especially if the game uses a hardware cursor instead of rendering the cursor itself as part of the game UI).
Also high refresh rate monitors make it slightly easier to overlook the lag (though it still is possible to tell - mine is a 165Hz monitor after all and i can still notice, it just doesn't annoy me as much as on a 60Hz monitor).
For most modern gaming monitors, this isn't a huge deal. Cap your game at 140 FPS on a 144hz display and it will feel as snappy as it probably would have uncapped. Though if you have a lower end (or ultra high resolution) display that caps out at something much lower, like 60, then I can definitely see how leaving it uncapped with VRR disabled would feel a lot snappier.
Early Freesync-branded displays could also be a bit of a crapshoot for a variety of reasons, but this has gotten much better in the last 5-6 years.
That sounds very weird to me, why would that be the case?
(also FWIW i'm using Linux so a system-wide cap isn't exactly possible, though at least with games i can simply run them via mangohud)
My understanding of why this causes a problem is that the CPU starts running ahead of the GPU, and queues up frames to be rendered. So it shouldn't be a problem with games that support Nvidia Reflex or some other feature to limit pre-rendered frames.
This is only true in certain situations. For non-fullscreen windows it requires that your GPU driver support a feature called "Multiplane Overlay" which is not supported on Nvidia cards before RTX 20 series (probably not older AMD cards either though I'm not sure). A lot of people have disabled it because they've experienced bugs like flickering or stability issues. And a lot of random features will also disable it without notice, like monitor rotation or 10-bit color.
I didn't permanently kill it like in the article, though. Just killed the process and let it restart.
I don't know for sure that dwm.exe itself was the cause. It could have been an issue with some of the endpoint management crap my employer forces on users, somehow, or maybe MS PowerToys (though I think I eventually ruled that out at some point). But killing dwm.exe fixes it.
I gotta say coming back to Windows for a while was a real shock for me. I can't believe how much basic stuff was more or less broken.
Maybe DWM restarting also kills and reinitializes the window messages mechanism?
>> 2 years ago
How often do you expect a single purpose program that's less than 200 LoC needs to be updated?
There's also this weirdness that DXGI always adds 3 frames of latency, because that's the default value unless explicitly changed by the application (https://learn.microsoft.com/en-us/windows/win32/api/dxgi/nf-...) - don't be confused by the "maximum" in the name, it's just consistently adding 3 frames of latency (at least on my Win10 machine).
Don't know if this has changed in more recent DXGI versions, but if you want to be backward compatible as much as possible, those are not an option.
The DXGI APIs are such a completely random collection of functionality that I really wonder if there's any forward thinking at all. If anything, at least the defaults are all wrong.
Never had any issue like this until I had to replace a monitor, and the newer one doesn’t keep HDMI/DP signals alive at all when the display sleeps, causing Windows to think it disconnects.
It’s such a stupid and common thing that the “PersistentWindows” tool exists to put the windows back in position after W10 fucks up everything from the monitor disconnect. So it’s not a stretch to think dwm.exe has issues with it as well.
(sorry, dwm (X11) having served me well for years, I had to make that joke).
The source was simple enough: get debug privileges, kill and suspend some processes, resume and if still missing restart, but I was puzzled at this function:
DWORD64 GetLPSTRHash(LPSTR s){
//more efficient string comparison
DWORD64 h=0;
BYTE c;
while((c=*s++)) h=(h<<5)+h+c;
return h;
}
a) Why is an optimized string compare needed here? Even iterating a few hundred processes I would not have thought a simple (and likely already optimized) strcmp would be a hotspot
b) Why does this work as a good hashing function? It seems very simple: to the existing value, add a bitshift of the existing value plus the character. Googling shows some people referring to it as the Wang hash, in the context of pseudorandom numbers on GPUs. The actual content I can find on Wang’s hashing shows much larger (and to me more expected) algorithms, eg http://burtleburtle.net/bob/hash/integer.html
It's pretty poor, and slow on modern systems. It's known as the djb2 hash. (h << 5) + h is a way of writing 33*h without needing multipliers.
It fails pretty much every modern statistical test you can throw at it: https://gitlab.com/fwojcik/smhasher3/-/blob/main/results/per...
It's redeeming quality is that the code size is absolutely tiny, and that 33*h mod 2^64 is a reversible map, so if your input data is randomly distributed at least your output will be as well.
Random distribution of outputs does seem to minimise collisions on as a small an input set as a list of processes so I suppose the risk of killing the wrong process is minimal. I do think if I used the app I’d replace it though.
Unless, you didn't install the correct driver and used standard vga driver, or like in a vm which doesn't provide gpu acceleration.
https://learn.microsoft.com/en-us/windows/win32/direct2d/com...
"GDI is hardware accelerated on Windows XP, and accelerated on Windows 7 when the Desktop Window Manager is running and a WDDM 1.1 driver is in use. Direct2D is hardware accelerated on almost any WDDM driver and whether or not DWM is in use. On Vista, GDI will always render on the CPU."
Especially follow the YouTube links demonstrating the problem: https://www.youtube.com/watch?v=ay-gqx18UTM https://www.youtube.com/watch?v=ToFgYylqP_U
The main reason is that your game time and the monitor's "time" are not really progressing in sync and even with vsync you are actually reacting on what the monitor did in the "past". This is why it isn't a problem on fixed platforms like the Amiga since you more or less know how fast the system is and can simply use vsync for game updates too (in other words make the game dependent on the framerate and just ensure the framerate is more or less constant, which is easy on fixed hardware but much harder on something like the PC).
FWIW this is still a problem, but at least a "hack" that has become a bit common since the video and article were published (and Croteam also did) is to "smooth out" the time progression by averaging the time deltas of the last few cycles. This doesn't fix the core problem but it makes the "heartbeat" less likely to happen and be noticeable at the cost of -mostly imperceptible- drift between game time and real time (that you can always reset if it becomes too large anyway).
I was surprised, because I thought using 3D acceleration and compositing would be faster.
Also, I run the VM at half res and used DPI workaround (.manifest file) to let Windows scale the VM instead of VirtualBox (VirtualBox scaling is very slow for some reason).
You lost me there. There needs to be real numbers measured, or the effect never existed.
Sometimes you get sluggish performance context switching app windows.
Task Manager and Resource Monitor shows that everything looks okay
- CPU - Memory - Disk - Network All running at less than 20% - yet computer feels sluggish switching apps.
What is interesting is that two computers with seemingly similar hardware - same corporate issue manufacturer can have different performance.
Surely there is something in SysInternals to help track down this issue.
Killing explorer.exe makes alt-tab instant.
I do run MS SQL Server and several IntelliJ IDEs at once, so it feels slow.
8gb of DD3 ram, 1.1ghz 4c/4t CPU from 2016. Many people who buy this will have it for at least five years. This is what the average computer experience looks like, just imagine how windows runs on this.