High-DPI and dynamic DPI changing support for Windows #224

GabrielMajeri · 2017-07-13T12:01:02Z

winit currently cannot be used to create cross-platform high-DPI aware applications (see issue #105). This commit adds support for creating high-DPI aware applications for Windows.

The 2 main changes of this pull request:

the addition of code to call the various Windows functions to make the process high-DPI aware.
a new event, DPIChanged, that informs the users of the winit library that they should handle the new DPI.

I've also added a new high-dpi.rs example to showcase what this pull request does.

Visual example

This is a normal window, on which I've written text using GDI.

This is the same window, but after a DPI change. Notice how the text is blurry - Windows does not know the app is aware of high DPI displays, and therefore scales the rendered bitmap.

After the code changes, the text looks fine, even at higher DPI.

However, high-DPI support means that the user code also has to adapt to higher DPI. The example uses the same font and layout at all DPIs - this is bad, it should be calculating a new layout and choosing a new font based on DPI, but that is not the concern of the winit library.

The reason why the text is unreadable below is because I didn't account for high-DPI when writing the rendering code.

DPI changed event

While on Windows 7 DPI can only be changed by logging out, therefore closing all programs, and logging in again, starting with Windows 8 DPI can be dynamically changed, or differ from monitor to monitor.

Therefore I added a new WindowEvent, the DPIChanged event, which is sent when the window receives the WM_DPICHANGED message.

Implementation

The code I added uses the already existing shared_library dependency. It tries to load, in order, the functions for setting DPI awareness for Windows 10, Windows 8, and Windows Vista.

If those DLLs are missing or lack the functions, or if the process is already high-DPI aware (through a manifest), no harm is done.

Further changes

It would be great to add a MonitorId::get_monitor_dpi() function, which returns the DPI of the monitor on Windows 8 or newer, and the same system DPI for all monitors on Windows 7 or older.

LPGhatguy · 2017-07-13T17:41:11Z

I had a less comprehensive pull request in #185 -- I think we came to the idea that it might be better to signal high DPI awareness via a manifest instead of at runtime.

@retep998, did your manifest linking investigation lead to any conclusions?

GabrielMajeri · 2017-07-13T17:52:35Z

Embedding a manifest isn't too hard. Currently in my apps I use the embed-resource crate, which allows embeding a manifest by using a simple .rc file.

The problems with this approach would be:

it wouldn't work if the winit library is built as a separate dynamic library, because the manifest must be in the .exe, not the .dll.
we don't know what the user wants in the manifest. There could be additional settings required, and this approach only allows one manifest in it, there is no way to combine manifests.

Reimplement platform_window on win32

retep998 · 2017-07-14T02:47:22Z

it wouldn't work if the winit library is built as a separate dynamic library, because the manifest must be in the .exe, not the .dll.

When is winit ever built as a separate dynamic library? 99% of the time all rust crates are statically linked together.

we don't know what the user wants in the manifest. There could be additional settings required, and this approach only allows one manifest in it, there is no way to combine manifests.

If Rust would finally let us specify arbitrary linker arguments, then you could use /MANIFESTINPUT to specify manifest input which is merged together. That way you can just set the DPI awareness and leave the rest up to the user.

Ralith · 2017-07-14T05:01:00Z

When is winit ever built as a separate dynamic library? 99% of the time all rust crates are statically linked together.

Rust may be used to build a dynamic library to be loaded by foreign code. First-class support for this use case is one of rust's big selling points.

If DPI awareness needs to be set in the manifest, and cargo won't yet let us just hardware it to "aware," it seems like the only behaviorally predictable solution is a documentation one.

GabrielMajeri · 2017-07-14T05:25:30Z

If Rust would finally let us specify arbitrary linker arguments

I agree that this would be the best solution for building .exes, although if winit is built into a DLL we'd still need these runtime calls to ensure the process as a whole is high-DPI aware.

This idea of loading function pointers and then calling the functions to set DPI awareness is used by GLFW. Of course, GLFW is more often than not loaded as a DLL, but as @Ralith said, someone could build a cdylib crate that uses winit.

seems like the only behaviorally predictable solution is a documentation one.

That could work, but we can't guarantee users of the library will do that. And since high-DPI screens aren't that common, the users of the winit library might not realize their apps are not high-DPI aware.

If winit handles window creation and management then it only seems logical to work as-is on all hardware.

As I said before, high-DPI support also involves some work done by users of the library, but by providing a cross-platform API of getting DPI and being informed of DPI changes, maybe users will also read up on high-DPI support and include it in their apps.

Ralith · 2017-07-14T06:43:47Z

This idea of loading function pointers and then calling the functions to set DPI awareness is used by GLFW

I don't know the APIs in question, but it's probably not appropriate for winit-in-a-cdylib to automatically set the entire process to high DPI, if for example rust code is being used as a plugin that needs to play well with other existing code that has its own opinions.

tomaka · 2017-07-14T06:52:58Z

Even for winit-as-a-regular-library it's probably not a great thing to set a process-global option.

GabrielMajeri · 2017-07-14T07:18:42Z

These option can only be changed once, anyway. If the user wants to override it, the user only has to call these functions before winit. If the user's app has a manifest, that will also take priority.

The method @retep998 recommends, using manifests, would mean the user wouldn't be able to make the app DPI unaware later.

retep998 · 2017-07-14T07:24:32Z

I don't think winit should automatically set the DPI awareness. Although I do think it should provide the ability to change the DPI awareness when the user explicitly asks for it.

…inite/winit into fix-hidpi-windows

GabrielMajeri · 2017-07-14T07:48:39Z

I've refactored the code. High-DPI awareness is now opt-in. The user has to call set_process_high_dpi_aware to make the process high-DPI aware. Also added some documentation linking to the page for app manifests.

retep998 · 2017-07-14T07:53:27Z

src/platform/windows/window.rs

@@ -44,7 +44,7 @@ impl Window {
    {
        let mut w_attr = Some(w_attr.clone());
        let mut pl_attr = Some(pl_attr.clone());
-
+        


Ew trailing whitespace.

That was in the original window.rs. I've removed it now.

[skip ci]

This is the right function to use according to the documentation.

kryptan · 2017-10-02T11:05:54Z

There is already the Window::hidpi_factor() function which currently always returns 1.0 on Windows. This PR doesn't change it while it probably should. I think value returned from that function should have the same type as parameter in the DPIChanged message.

Documentation for the WM_DPICHANGED message says that "the values of the X-axis and the Y-axis are identical for Windows apps". Do we need to confuse users with different values for X and Y if they are always the same?

Also, if you report this value as DPI then it is necessary to say in the documentation what is the default, non-scaled value is.

kryptan · 2017-10-04T13:01:31Z

I see that there is a deprecated SetProcessDPIAware function which can be used on Vista to set DPI awareness and is used in this PR if newer APIs are not available. But I don't see any way to actually get the DPI on Vista. WM_DPICHANGED is only sent on Windows 8.1. I checked all functions in the High DPI Reference and all functions for getting DPI are available only on 8.1 or newer.

GabrielMajeri · 2017-10-04T13:25:05Z

I'm no longer working on supporting this pull request. If anyone wants to reuse some of the code, feel free to.

@kryptan Could you also post your observations on issue #105? We should at least keep the discussion alive there.

GabrielMajeri added 4 commits July 13, 2017 12:17

Create high-DPI test

ca159c6

Add code to make application high-DPI aware

bba5978

Add DPIChanged event

f27978a

Fix travis-ci build

3b6c7f1

tomaka added 2 commits July 13, 2017 21:14

Reimplement platform_window on win32

7a1a266

Merge pull request #225 from tomaka/win32-platform-window

a1d2ee6

Reimplement platform_window on win32

GabrielMajeri added 6 commits July 14, 2017 10:35

Create high-DPI test

13b0fd2

Add code to make application high-DPI aware

e1434a3

Add DPIChanged event

8906b33

Fix travis-ci build

f0fc332

Merge branch 'fix-hidpi-windows' of https://github.com/GuildMasterInf…

8866570

…inite/winit into fix-hidpi-windows

Refactor high-DPI code to be opt-in

eb6b024

Revert changes in window.rs

2f4cf97

retep998 reviewed Jul 14, 2017

View reviewed changes

GabrielMajeri added 6 commits July 14, 2017 10:54

Revert more changes

c67a885

Remove trailing whitespace

603a2f5

Add more documentation to the DPIChanged event

45d5945

Remove unnecessary newline

a90fd2e

Replace tabs with spaces

d47abea

[skip ci]

Fix more tabs

06f418c

[skip ci]

GabrielMajeri added 3 commits July 14, 2017 11:14

More spacing issues in high_dpi.rs

45c7b44

[skip ci]

Use the ReleaseDC function in the example

3f7cd67

This is the right function to use according to the documentation.

Fix Appveyor build

82d6ae2

GabrielMajeri closed this Oct 4, 2017

kryptan mentioned this pull request Oct 11, 2017

Handle hidpi scaling. #105

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

High-DPI and dynamic DPI changing support for Windows #224

High-DPI and dynamic DPI changing support for Windows #224

GabrielMajeri commented Jul 13, 2017 •

edited

Loading

LPGhatguy commented Jul 13, 2017

GabrielMajeri commented Jul 13, 2017 •

edited

Loading

retep998 commented Jul 14, 2017

Ralith commented Jul 14, 2017

GabrielMajeri commented Jul 14, 2017 •

edited

Loading

Ralith commented Jul 14, 2017

tomaka commented Jul 14, 2017

GabrielMajeri commented Jul 14, 2017 •

edited

Loading

retep998 commented Jul 14, 2017

GabrielMajeri commented Jul 14, 2017

retep998 Jul 14, 2017

GabrielMajeri Jul 14, 2017

kryptan commented Oct 2, 2017

kryptan commented Oct 4, 2017 •

edited

Loading

GabrielMajeri commented Oct 4, 2017 •

edited

Loading

High-DPI and dynamic DPI changing support for Windows #224

High-DPI and dynamic DPI changing support for Windows #224

Conversation

GabrielMajeri commented Jul 13, 2017 • edited Loading

Visual example

DPI changed event

Implementation

Further changes

LPGhatguy commented Jul 13, 2017

GabrielMajeri commented Jul 13, 2017 • edited Loading

retep998 commented Jul 14, 2017

Ralith commented Jul 14, 2017

GabrielMajeri commented Jul 14, 2017 • edited Loading

Ralith commented Jul 14, 2017

tomaka commented Jul 14, 2017

GabrielMajeri commented Jul 14, 2017 • edited Loading

retep998 commented Jul 14, 2017

GabrielMajeri commented Jul 14, 2017

retep998 Jul 14, 2017

Choose a reason for hiding this comment

GabrielMajeri Jul 14, 2017

Choose a reason for hiding this comment

kryptan commented Oct 2, 2017

kryptan commented Oct 4, 2017 • edited Loading

GabrielMajeri commented Oct 4, 2017 • edited Loading

GabrielMajeri commented Jul 13, 2017 •

edited

Loading

GabrielMajeri commented Jul 13, 2017 •

edited

Loading

GabrielMajeri commented Jul 14, 2017 •

edited

Loading

GabrielMajeri commented Jul 14, 2017 •

edited

Loading

kryptan commented Oct 4, 2017 •

edited

Loading

GabrielMajeri commented Oct 4, 2017 •

edited

Loading