Opened 20 months ago

Closed 9 months ago

#18288 closed enhancement (fixed)

Make CMake-built samples on MSW DPI-aware

Reported by: pb101 Owned by:
Priority: normal Milestone: 3.1.4
Component: samples Version: dev-latest
Keywords: MSW CMake DPI manifest Cc: pbfordev@…
Blocked By: Blocking: #18474
Patch: no


I have noticed that CMake-built samples on MSW are blurry when run on non-default DPI systems. This may not make the best impression on first-time potential users of the library nor does it look good in general.

I know that wxWidgets still does not fully support high DPI on MSW but I wonder if it would be possible to build at least some (hopefully most) samples as DPI-aware without any adverse effects on their function.

Unfortunately I do not know much about CMake but perhaps it would be possible to do it both for MSVC and GCC by adding an extra step embedding a manifest containing DPI-awareness information...

BTW, the minimal sample (the only sample providing a post-VC9 VS project) VC15 project has DPI-Awareness set to "None" as well, not sure whether it is by design or not.

Change History (6)

comment:1 Changed 20 months ago by MaartenB

When developing per-monitor dpi-awareness I added the following line to wx_add_sample in functions.cmake

list(APPEND src_files ${wxSOURCE_DIR}/samples/dpi.manifest)

And dpi.manifest (for PerMonitorV2) looked like

<?xml version="1.0" encoding="UTF-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="" processorArchitecture="amd64" publicKeyToken="6595b64144ccf1df" language="*" />
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <requestedExecutionLevel level="asInvoker" uiAccess="false" />
    <asmv3:windowsSettings xmlns="">
  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
      <!-- Windows Vista -->
      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}" />
      <!-- Windows 7 -->
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" />
      <!-- Windows 8 -->
      <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />
      <!-- Windows 8.1 -->
      <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" />
      <!-- Windows 10 -->
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />

You can do the same with <dpiAware>true</dpiAware>.
There are already some manifests in include/wx/msw that are used when using GCC compiler. I don't know if and how the Visual Studio projects cn be updated with manifest info.

comment:2 Changed 11 months ago by vadz

  • Blocking 18474 added

comment:3 Changed 9 months ago by pb101

  • Cc pbfordev@… added

I want to refresh this idea, not only because #18528.

If you do not like to enable this unconditionally, there could be a build switch and/or each sample could have a property indicating whether it is DPI-aware ready. Ideally all bundled samples should work well with high DPI and then perhaps even provided MSVS make and project files could have this setting enabled.

Just to make sure, I am not talking about Per Monitor V2 awareness, just the basic regular one.

comment:4 Changed 9 months ago by vadz

  • Milestone set to 3.1.4
  • Status changed from new to confirmed

I think it makes sense to enable per monitor v2 if we enable anything at all (of course, we should also enable simple awareness for pre-MSW 10 systems too). And while I'm pretty sure there are going to be some problems with it right now, I think it could be a good idea to still enable it for 2 reasons:

  1. This will make these problems easier to find and so, hopefully, faster to fix.
  2. People copying our makefiles (which typically happens for new applications, which don't risk to suddenly get broken after this change) will get DPI awareness for free.

It's probably too late to do it for 3.1.3, but I'd like to do it before 3.2.0.

comment:5 Changed 9 months ago by MaartenB

I added a CMake option to set the DPI Awareness in PR1622. It works for (at least) VS solutions (msvc) and MinGW Makefiles (gcc/clang).

comment:6 Changed 9 months ago by MaartenB

  • Resolution set to fixed
  • Status changed from confirmed to closed
Note: See TracTickets for help on using tickets.