Opened 6 years ago

Closed 9 months ago

#16116 closed defect (fixed)

Restore DPI awareness for wxMSW applications

Reported by: ericj Owned by:
Priority: normal Milestone:
Component: wxMSW Version: dev-latest
Keywords: HiDPI awareness Cc: tobias@…, andres.clari@…, asmwarrior@…, pbfordev@…
Blocked By: Blocking: #18474
Patch: no


I don't think it was good idea to remove the SetProcessDPIAware() call in r75740 .

If you look at the screenshot comparing the minimal sample from 3.0.0RC1 and 3.1.0 next to each other, the regression is clearly visible. This happens when the user sets the display to 150% ("Screen resolution" -> "Make text and other items larger or smaller").

Same effect under Windows 7 and 8.

Attachments (3)

wx_dpi_aware_300_310.png download (80.7 KB) - added by ericj 6 years ago.
wx_auidemo_300rc1_150percent.png download (132.8 KB) - added by ericj 6 years ago.
wx_auidemo_310_150percent.png download (181.1 KB) - added by ericj 6 years ago.

Download all attachments as: .zip

Change History (21)

Changed 6 years ago by ericj

comment:1 Changed 6 years ago by ericj

You should look at the screenshot in an external viewer. Trac scales the image, so the texts on both sides look blurry. In 100% resolution, the difference is more obvious.

comment:2 Changed 6 years ago by vadz

  • Keywords HiDPI added; dpi removed
  • Status changed from new to confirmed
  • Summary changed from [MSW] DPI awareness again to Restore DPI awareness for wxMSW applications

This is not unexpected, of course, and it is bad, but I think it's better to have blurry text than completely unusable icons/buttons in AUI and so on. Of course, the real solution is to fix AUI and the rest and then reenable SetProcessDPIAware().

I'd encourage you and anybody else who can test under Windows 8 in high DPI to open bugs for individual problems in AUI and elsewhere which appear if you add this call back and make them blocking for this ticket so that we could resolve it once all the other bugs are fixed.


comment:3 Changed 6 years ago by ericj

What exactly are the problems with AUI supposed to be? I made another test with the aui demo and while it doesn't look perfect with dpi-awareness enabled, i think it looks better than without it. And it's still usable.

I also tested the "widgets" sample and didn't find any problems at all. So, in general i'd say that wxWidgets is dpi-aware enough to enable it by default. With the potential bigger public exposure of wxWidgets caused by GSoC, i'm a little concerned that new users testing wx for the first time, might get a bad first impression if they run the samples and see blurry text all over the place.

Changed 6 years ago by ericj

Changed 6 years ago by ericj

comment:4 Changed 6 years ago by vaclavslavik

then reenable SetProcessDPIAware().

Actually, didn't we discuss that it is bad idea to use in some other ticket? E.g. Windows 8 certification requires that DPI awareness is set in the manifest and not in code, so regardless of this bug, the changes of r75740 should remain and be replaced with equivalent changes to the (default) manifest.

comment:5 Changed 6 years ago by vadz

The icons are clearly too small in wxAUI. They're still usable at 150% but I think they would be completely unusable (i.e. it would be impossible to understand what they are) at 200% or higher.

We can't do anything about the manifest at wx level as we just use the compiler-generated one with any non ancient MSVC versions, it's something that can only be done at the application level (which is also the point, I think).

comment:6 Changed 6 years ago by TcT

  • Cc tobias@… added

comment:7 Changed 6 years ago by dconnet

I am pretty sure it was discussed elsewhere, and it is a bad idea. My application is _not_ DPI aware. This would force it (except that I do use the manifest, hence this call would be ignored).

While I agree the library should be aware and do the right thing, the library should not force the application to be aware. Especially since the call can be made only once. So if WX calls this before my app can, I'm SOL.

comment:8 Changed 4 years ago by vadz

For the record: if we want to properly implement high DPI support under Windows 10, we actually should handle WM_DPICHANGED and then call SetProcessDpiAwareness(PROCESS_PER_MONITOR_DPI_AWARE) to properly handle monitors using DPI different from the system default.

comment:9 Changed 4 years ago by paulclinger

I tend to agree with dconnet. I was initially disappointed when the setting was removed, but I think it's for the better, as it can't be cleanly initiated from a DLL anyway (which is how I use wxwidgets in my application).

I'm currently using SetProcessDpiAwareness form my main executable, but plan to switch to using a manifest.

comment:10 Changed 4 years ago by dconnet

I've been using a manifest for a while. And "fixing" other applications that have obviously never been tested in a hi-dpi setting (or mixed monitor - Adobe Reader, I'm looking at you!) by exporting the existing manifest with mt.exe and modifying it. For most, that means setting dpiAware to false. In AR's case, changing 'true/pm' to 'true' (And setting the registry setting to prefer external manifests)

comment:11 Changed 2 years ago by andresclari

  • Cc andres.clari@… added

Any news on this, default applications and samples are still not HiDPI aware without setting the code for it.

comment:12 Changed 2 years ago by MaartenB

This requires adding a custom manifest to the generated project files. Does bakefile have an option to specify a manifest?
The Visual Project file should contain something like this (minimal sample):

   <AdditionalManifestFiles>..\..\include\wx\msw\dpi.manifest %(AdditionalManifestFiles)</AdditionalManifestFiles>

Where dpi.manifest contains:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <application xmlns="urn:schemas-microsoft-com:asm.v3">
      <dpiAware xmlns="">true</dpiAware>

For GCC builds the manifest files are already used so dpiAware is easy to add. For CMake we can just add dpi.manifest as additional source file.

comment:13 Changed 2 years ago by vadz

I wonder if we could handle this at wx/msw/wx.rc level?

This would still require defining some wxSUPPORTS_HIGH_DPI, i.e. be opt-in, however.

comment:14 Changed 2 years ago by MaartenB

I tried that, but it results in this error:

1>CVTRES : fatal error CVT1100: duplicate resource.  type:MANIFEST, name:1, language:0x0409
1>LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt

If I modify the VS project with <GenerateManifest>false</GenerateManifest> it works.

comment:15 Changed 2 years ago by ollydbg

  • Cc asmwarrior@… added

comment:16 Changed 12 months ago by vadz

  • Blocking 18474 added

comment:17 Changed 9 months ago by pb101

  • Cc pbfordev@… added

I think this ticket can be closed now.

comment:18 Changed 9 months ago by vadz

  • Resolution set to fixed
  • Status changed from confirmed to closed

Indeed, we now have wxWITH_DPI_MANIFEST, similar to but better than the previously proposed wxSUPPORTS_HIGH_DPI, thanks to Maarten.

And thanks for the reminder about this ticket.

Note: See TracTickets for help on using tickets.