I cannot get this to work no matter what I do.
Theres really no way to make my 4k monitor 125 or 150% and leave my 1080p at 100%?
I read through your registry update. I understand adding HIGHDPIAWARE to all of those Windows applications, at lerast. I'm not sure what the first three keys do, it would be nice to know what affects they have (I know you say it's a bunch of complicated stuff, but again, I'm curious).
Okay, now the real question( s ). I'm using a Surface Pro 2, which looks great at 150% DPI, and two 23" external monitors, which look great at 100% DPI. The closest I've gotten to making everything look good together is using the Display DPI properties, letting Windows adjust the DPI per monitor, and selecting the second-to-Smallest setting. This results in most applications looking good everywhere, with the exception of some Windows components (which I guess you are fixing) and software like Microsoft Office.
I personally have tried adding the HIGHDPIAWARE values for winword.exe or outlook.exe, and received mixed results... In some cases, the application would lay out like a desktop app and be clean and sharp, but then look terrible on the Surface itself, or in other cases the app would look great on the tablet portion but then on the desktop monitor size itself with everything all spread out so touch could work... I don't know.
If we use this registry update - what does it fix, exactly? Am I correct in saying this doesn't allow per-monitor DPI setting (I can't tell Windows to make my externals 100% and the SP2 150%) but it makes many Windows applications DPI aware so they'll adjust the way they should on the different monitors?
I checked out the OP finding this thread after a couple of months and the file attached does the least intrusive thing that always seems to work--the only case where it doesn't that I've seen is on some files flagged as protected in the Windows folder.
It adds a right click context menu entry to .exe files to "Disable DPI scaling" which is equivalent to clicking Properties, Compatibility, Disable display scaling on high DPI. It allows multiple selections of .exe files and even folders. Using it on a folder causes it to traverse the folder tree and mark all executables inside the folder and subfolders as DPI-aware.
There is a more powerful, but less reliable method I've attached to this response (DPI Fix.reg). It doesn't always work, but when it does it prevents from having to manually add files to the high-DPI-capable list. I've seen best results when using right after a fresh install, and apparently getting similar results after deleting the AppCache value under the AppCompat key. I didn't bother to track down the exact cause/effect relationship once apps started behaving the way I wanted.
Both can be used at the same time
Since the goal is to mark the app as DPI capable and allow it to scale using its own WMF methods, you will get unpredictable results whether the app shows up properly scaled depending on your definition of that. The 8.1 way is to make everything big and adds a blurry looking effect to the upscaled window. This marks the app as capable of doing its own scaling even if it is not marked that way in its application manifest (an internal list of specs and functions that are part of the app.)
Most of the time that makes apps scale to the correct dimensions without blurriness. Sometimes an app won't scale up at all, and sometimes it will scale up halfway--with elements out of place on a properly resized canvas, for example. My goal was to prevent the automatic upscaling and blurriness that results. So to your question about per-monitor DPI, I actually don't know how it works on different sized screens since mine are all the same size. I'm guessing it should disable that on apps it's applied to since Windows is led to believe they are high-DPI capable.
The registry edits made everything wonky and weird.
Thanks for all the effort you put into it though.
I take it to reverse the effect I just have to empty all the values set with this?
10/10 would not run again.
Thank you Aph for posting your solution to this blurry DPI fiasco!
The AppCompatFlags HighDpiAware trick wouldn't work for me and, after some investigation, the culprit turned out to be the __COMPAT_LAYER=HighDpiAware variable in HKCU\Environment. This apparently makes no sense, as both the variable _and_ the flag are even documented somewhere, and are supposed to work like that. I thought that it might have been caused by a type mismatch but neither the type REG_SZ nor REG_EXPAND_SZ makes it work. Anyway, getting rid of it was what made the blur go away, so I thought I'd share this fix.
I tested this on mmc.exe. For running from the command line, I also needed to wipe the variable from the HKLM environment, HKCU was enough for Win+R, Win+X and Win+W style execution.
BTW, you have "^ HIGHDPIAWARE" in the .reg file, and "~ HIGHDPIAWARE" in your .bat file. Windows seems to use ~ when creating its own AppCompat entries. To the extent that I've checked it, both, as well as a plain "HIGHDPIAWARE" seem to work just the same. I guess the latter just replaces all the flags, whereas ~ and ^ are some sort of logical or bit-wise OR but if anyone knows the exact difference in how ^ and ~ are evaluated, please do shed some light.
Thanks again, Aph!
Update: It appears that setting __COMPAT_LAYER to "HighDpiAware" or "HIGHDPIAWARE" has the same effect as setting it to "blah", that is: (1) the flag is not intepreted, (2) it also stops any registry flags from being processed. I'm testing this on a fresh installation of W8 SP1 Dec 2014 with all the available updates and hotfixes installed as of now, so it'd be interesting to know if it used to work before what version it was on. Or perhaps there's another explanation....
Last edited by Eman Resu; 19 Apr 2015 at 13:06. Reason: more information re: __COMPAT_LAYER