DPI for everyone #548

francesca64 · 2018-06-03T03:39:25Z

Fixes #62
Fixes #105
Fixes #169
Fixes #315
Fixes #332 (big thanks to @kryptan for the initial work on Windows!)
Fixes #337
Fixes #469
Fixes rust-windowing/glutin#1025

Alright, it was quite the undertaking, but I believe I've finished this on X11, Windows, macOS, iOS, Android, and Emscripten.

Some caveats:

The Intel OpenGL driver on Windows still has some problems in mixed-DPI environments. It doesn't happen with DirectX or Vulkan (and OpenGL with Nvidia works fine), and it will only affect people who either A) have multiple monitors of differing scale factors, or B) change the scale factor after login. The issue itself is just that there's a small black/background-colored gap below the titlebar; this doesn't happen without DPI awareness, but I think this is an acceptable trade-off. Besides, if users disagree, it's still possible to disable DPI awareness using EventsLoopExt.
Android still returns a DPI factor of 1.0. As far as I can tell, getting the real value won't be possible until Initial JNI support rust-mobile/android-rs-glue#116 is sorted out. However, once that's filled in the code I've added here should do all the right conversions.
I couldn't really test Emscripten, since I was unable to get anything to actually run in my browser.
iOS was an adventure, and I ended up reworking glutin's iOS backend (it's apparently been broken for quite some time). I still never got anything to render, but I can at least say that it reported the correct sizes and DPI factor. I've unfortunately introduced a small amount of GL-specific code to the iOS backend here; I plan on doing some restructuring and fixing that before this makes it into a release, but I didn't want to make this PR any more huge and monolithic than it is already.
My solution for Wayland was just to comment things out in src/platform/linux/mod.rs and say "@vberger will figure this out later"

That said, this PR is functionally complete. The only reason I've labeled it WIP is because it's still completely undocumented! I just wanted an opportunity for feedback before I start fussing over doc comments. (I also noticed that I left a // TODO: Adjust min+max size in the Windows backend, whoops)

I won't reiterate what I wrote in CHANGELOG.md. Besides there, the other files I recommend looking at are src/dpi.rsand src/window.rs. You can obviously also test this, and I've provided some partial migrations of various things to help with that:

glutin - everything should work except for the examples, and note that GlWindow::resize doesn't yet explicitly take PhysicalSize.
gfx pre-ll - everything should work except for the examples.
alacritty - it seems fine on macOS, though on X11 it seems to "double upscale" on HiDPI displays. This is almost certainly a result of the math in the auto-resize Alacritty does after creation, but I couldn't find where it does that.

Migrating can be tedious, but isn't hard, and the more explicit API resulted in me fixing some bugs in my own applications. Overall, I'm pretty satisfied, but if anyone has objections, I'm in no rush to merge this. I want to release a 0.15.1 with various regression fixes before introducing any breaking changes like this.

elinorbgr · 2018-06-03T07:07:34Z

My solution for Wayland was just to comment things out in src/platform/linux/mod.rs and say "@vberger will figure this out later"

Do you want me to take my #341 PR and integrate these changes into a PR to your PR branch ?

francesca64 · 2018-06-03T12:15:59Z

I'm glad I merged #547, since this failed on 1.24...

@vberger that's probably a good idea; besides making things cleaner, you integrating the new types before this merges would be an effective form of review for them.

rukai · 2018-06-03T12:38:37Z

CHANGELOG.md

@@ -3,6 +3,16 @@
 - On X11, the `Moved` event is no longer sent when the window is resized without changing position.
 - `MouseCursor` and `CursorState` now implement `Default`.
 - `WindowBuilder::with_resizable` implemented for Windows.
+- On X11, exiting fullscreen no longer leaves the window in the monitor's top left corner.
+- **Breaking:** `Window::get_hidpi_factor` has been renamed to `Window::get_hidpi_factor` for better consistency. `WindowEvent::HiDPIFactorChanged` has been renamed to ``WindowEvent::HiDpiFactorChanged``. DPI factors are always represented as `f64` instead of `f32` now.


I think it should be "Window::hidpi_factor has been renamed"

francesca64 · 2018-06-03T14:24:02Z

It turns out I'd already fully implemented min/max dimension DPI adjustment on Windows, but just forgot to remove the TODO comment.

rukai · 2018-06-04T01:11:39Z

@vberger I migrated pf sandbox to use this branch https://github.com/rukai/PF_Sandbox/tree/super-dpi
And since your commit I'm hitting this issue.

error[E0277]: the trait bound `*mut wayland_sys::client::wl_display: std::marker::Send` is not satisfied in `wayland_client::display::DisplayInner`
   --> pf_sandbox/src/vulkan/mod.rs:221:25
    |
221 |         let draw_text = DrawText::new(device.clone(), queue.clone(), swapchain.clone(), &images);
    |                         ^^^^^^^^^^^^^ `*mut wayland_sys::client::wl_display` cannot be sent between threads safely
    |
    = help: within `wayland_client::display::DisplayInner`, the trait `std::marker::Send` is not implemented for `*mut wayland_sys::client::wl_display`
    = note: required because it appears within the type `wayland_client::display::DisplayInner`
    = note: required because of the requirements on the impl of `std::marker::Send` for `std::sync::Arc<wayland_client::display::DisplayInner>`
    = note: required because it appears within the type `wayland_client::display::Display`
    = note: required because of the requirements on the impl of `std::marker::Send` for `std::sync::Arc<wayland_client::display::Display>`
    = note: required because it appears within the type `winit::platform::platform::wayland::window::Window`
    = note: required because it appears within the type `winit::platform::platform::Window`
    = note: required because it appears within the type `winit::Window`
    = note: required by `vulkano_text::DrawText::new`

The issue probably occurs with any vulkano project but I havnt had time to test.
It looks like a similar issue to #472

Edit

Just confirmed we get the same error with the vulkano triangle example:

error[E0277]: the trait bound `*mut wayland_sys::client::wl_display: std::marker::Send` is not satisfied in `wayland_client::display::DisplayInner`
   --> src/main.rs:406:14
    |
406 |             .begin_render_pass(framebuffers.as_ref().unwrap()[image_num].clone(), false,
    |              ^^^^^^^^^^^^^^^^^ `*mut wayland_sys::client::wl_display` cannot be sent between threads safely
    |
    = help: within `wayland_client::display::DisplayInner`, the trait `std::marker::Send` is not implemented for `*mut wayland_sys::client::wl_display`
    = note: required because it appears within the type `wayland_client::display::DisplayInner`
    = note: required because of the requirements on the impl of `std::marker::Send` for `std::sync::Arc<wayland_client::display::DisplayInner>`
    = note: required because it appears within the type `wayland_client::display::Display`
    = note: required because of the requirements on the impl of `std::marker::Send` for `std::sync::Arc<wayland_client::display::Display>`
    = note: required because it appears within the type `winit::platform::platform::wayland::window::Window`
    = note: required because it appears within the type `winit::platform::platform::Window`
    = note: required because it appears within the type `winit::Window`
    = note: required because it appears within the type `vulkano::swapchain::Surface<winit::Window>`
    = note: required because of the requirements on the impl of `std::marker::Send` for `std::sync::Arc<vulkano::swapchain::Surface<winit::Window>>`
    = note: required because it appears within the type `vulkano::swapchain::Swapchain<winit::Window>`
    = note: required because of the requirements on the impl of `std::marker::Send` for `std::sync::Arc<vulkano::swapchain::Swapchain<winit::Window>>`
    = note: required because it appears within the type `vulkano::image::SwapchainImage<winit::Window>`
    = note: required because of the requirements on the impl of `std::marker::Send` for `std::sync::Arc<vulkano::image::SwapchainImage<winit::Window>>`
    = note: required because it appears within the type `((), std::sync::Arc<vulkano::image::SwapchainImage<winit::Window>>)`
    = note: required because it appears within the type `vulkano::framebuffer::Framebuffer<std::sync::Arc<vulkano::framebuffer::RenderPass<main::scope::CustomRenderPassDesc>>, ((), std::sync::Arc<vulkano::image::SwapchainImage<winit::Window>>)>`
    = note: required because of the requirements on the impl of `std::marker::Send` for `std::sync::Arc<vulkano::framebuffer::Framebuffer<std::sync::Arc<vulkano::framebuffer::RenderPass<main::scope::CustomRenderPassDesc>>, ((), std::sync::Arc<vulkano::image::SwapchainImage<winit::Window>>)>>`

francesca64 · 2018-06-04T02:11:15Z

You have no idea how much of a relief it is when a notification is for something that isn't my fault.

Shouldn't this have been caught by this test? https://github.com/tomaka/winit/blob/19dd961752319276fa170c07e46963de9e3b589c/tests/send_objects.rs#L11-L15

rukai · 2018-06-04T02:17:23Z

running cargo test locally, it does actually fail although it fails in an example before it reaches your test:

error[E0277]: the trait bound `*mut wayland_sys::client::wl_display: std::marker::Send` is not satisfied in `wayland_client::display::DisplayInner`
  --> examples/proxy.rs:13:5
   |
13 |     std::thread::spawn(move || {
   |     ^^^^^^^^^^^^^^^^^^ `*mut wayland_sys::client::wl_display` cannot be sent between threads safely
   |
   = help: within `wayland_client::display::DisplayInner`, the trait `std::marker::Send` is not implemented for `*mut wayland_sys::client::wl_display`
   = note: required because it appears within the type `wayland_client::display::DisplayInner`
   = note: required because of the requirements on the impl of `std::marker::Send` for `std::sync::Arc<wayland_client::display::DisplayInner>`
   = note: required because it appears within the type `wayland_client::display::Display`
   = note: required because of the requirements on the impl of `std::marker::Send` for `std::sync::Weak<wayland_client::display::Display>`
   = note: required because it appears within the type `winit::platform::platform::wayland::event_loop::EventsLoopProxy`
   = note: required because it appears within the type `winit::platform::platform::EventsLoopProxy`
   = note: required because it appears within the type `winit::EventsLoopProxy`
   = note: required because it appears within the type `[closure@examples/proxy.rs:13:24: 19:6 proxy:winit::EventsLoopProxy]`
   = note: required by `std::thread::spawn`

francesca64 · 2018-06-04T02:27:01Z

Weird, cargo test passes for me, and I can run the proxy example fine in Weston.

@vberger feel free to just push directly to this branch.

rukai · 2018-06-04T03:28:30Z

To confirm the issue, I ran the following commands on a Digital Ocean vps of mine

rustup default stable
rustup update
git clone -b super-dpi https://github.com/francesca64/winit
cd winit
cargo test

I still get the proxy.rs build failures I posted above.

Maybe you need to cargo update or maybe you have modified files that arnt checked in or maybe you are using the wrong branch?

Doesnt explain why the travis is passing though!?!

elinorbgr · 2018-06-04T07:05:16Z

Aaaah, ok, this is an unforseen consequence of my last release of wayland-client, sorry for that. I definitly need better testing... ><

I'll correct this asap.

elinorbgr · 2018-06-04T07:28:39Z

Alright, wayland-client 0.20.9 is yanked, wayland-client 0.20.10 is released with the fix, and I added tests for that. All should be good again.

rukai · 2018-06-04T07:36:31Z

Thanks, that fixes it.

kryptan · 2018-06-05T04:06:06Z

The Intel OpenGL driver on Windows still has some problems in mixed-DPI environments. ... The issue itself is just that there's a small black/background-colored gap below the titlebar;

But I think coordinates of mouse events will still be computed correctly while rendering is incorrect. This will create a mismatch

yvt · 2018-06-05T04:54:35Z

src/platform/macos/window.rs

        unsafe {
-            let (width, height) = dimensions.unwrap_or((0, 0));
-            nswindow_set_min_dimensions(self.window.0, width.into(), height.into());
+            let dimensions = dimensions.unwrap_or_else(|| (!0, !0).into());


Hello, I think this line should be:

let dimensions = dimensions.unwrap_or_else(|| (0, 0).into());

Otherwise window.set_min_dimensions(None) crashes the application by changing the window size to a huge value.

Whoops, good catch. Looks like I got carried away with copy-pasting.

francesca64 · 2018-06-05T13:09:43Z

@kryptan that's really unfortunate. Hopefully Intel fixes this soon, since AFAIK there's nothing we can do about it, and I don't think it makes sense to postpone this for something that hopefully only affects a small subset of users.

chrisduerr · 2018-06-05T17:33:56Z

src/platform/linux/x11/util/randr.rs

+        (width_px as f64 * height_px as f64) / (width_mm as f64 * height_mm as f64)
+    ).sqrt();
+    // Quantize 1/12 step size
+    ((ppmm * (12.0 * 25.4 / 96.0)).round() / 12.0).max(1.0)


I don't really have a very deep understanding of this topic, but wouldn't the 96.0 here need to by the actual x11 screen DPI to properly support DPI on x11?

As far as I understand it 96.0 is only the default screen DPI on x11 and it could change based on a user's configuration. I'm not sure if in this context it's a different value that's always constant, but thought I'd just ask to properly understand this topic.

Actually it might be possible that this 96.0 here is just used to calculate the DPI factor you'd need to apply to a screen with 96 DPI to get the "proper" DPI scaling. So this is probably all working as intended.

I recommend reading the relevant issue #169 along with this blog post: http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/

After that, you'll have an understanding with the same depth as mine, or probably better, since I know for a fact that I glossed over some things. I might not get a chance to look into that constant today, since I still have a Windows bug to investigate and a burning desire to relax for the rest of the day.

Ah, GitHub only sometimes wants to update the page automatically, so I didn't see that. I do encourage being skeptical of this math, since I don't know who added it or when; I just know that it makes my eyes not hurt when using winit apps on my 1440p monitor.

Thanks a lot for the clarification and the helpful links to the documentation. Until now I've mainly just made guesses based on the math in alacritty and winit and took a short read through the freetype documentation.

Looks like this will give me some more insights, very much appreciated!

elinorbgr · 2018-06-15T08:39:49Z

🎉 🎉

You may need to remove your Cargo.lock file to be able to build. Thus you will start with fresh dependencies. Require the WINIT_HIDPI_FACTOR=1 environment variable set to 1 to work flawlessly on Linux X11. This was caused by a fix in WINIT. It seems that until now, reporting DPI was buggy on X11 [1]. DPI was already reported as 1. aflak is actually a special case for which a DPI of 1 is desired (at least for now with the current design). [1] rust-windowing/winit#548

…#548 NgsPF benefits at great extent from this PR <rust-windowing/winit#548> as it fixes various quirks regarding the HiDPI handling and window resizing that prevail in the current master branch of `winit`.

…rement This is finally possible thanks to the PR rust-windowing/winit#548!

francesca64 mentioned this pull request Jun 3, 2018

Handle hidpi scaling. #105

Closed

elinorbgr mentioned this pull request Jun 3, 2018

Implement hidpi support for wayland #341

Closed

francesca64 mentioned this pull request Jun 3, 2018

4k HiDPI monitor detected as 2560x1440 on Windows 10 #469

Closed

rukai reviewed Jun 3, 2018

View reviewed changes

francesca64 mentioned this pull request Jun 3, 2018

Expose get_physical_extents for the MonitorId #442

Closed

francesca64 added this to the HiDPI Support milestone Jun 3, 2018

This was referenced Jun 3, 2018

Examples rendered off-center or not all gfx-rs/gfx#1358

Closed

Fix DPI with 0 width/hight reported by xorg #544

Merged

francesca64 force-pushed the super-dpi branch from 5aab491 to dfe40b6 Compare June 3, 2018 18:06

yvt reviewed Jun 5, 2018

View reviewed changes

chrisduerr reviewed Jun 5, 2018

View reviewed changes

icefoxen mentioned this pull request Jun 6, 2018

Winit integration tracking ggez/ggez#391

Closed

francesca64 mentioned this pull request Jun 6, 2018

Strange resolution issues on macOS rust-windowing/glutin#1025

Closed

nixpulvis mentioned this pull request Jun 7, 2018

Allow disabling DPI scaling alacritty/alacritty#1355

Merged

This was referenced Jun 7, 2018

get_available_monitors() / get_primary_monitor() ergonomics #555

Closed

Windows & X11: Window::set_resizable #558

Merged

Incorrect viewport size on fullscreen with windows DPI scaling glium/glium#1654

Open

francesca64 and others added 14 commits June 14, 2018 11:32

Updated Windows events

f3d7920

Updated Linux events

6eb1643

Emscripten uses new API

343e527

Android uses new API

7652305

Fix Windows rebase error

9051197

CHANGELOG fixes

16c77b7

Fixed no_resize example

e3befe0

Fix build on Rust 1.24

bb479b1

Fixed CHANGELOG typos

14b1d0f

Improve initial setting of min/max size on Windows

324a76f

wayland: dpi-awareness

19506bc

Remove unused imports

d15b4b8

macOS: Fix min dimensions

7b69540

X11: Fix compilation

68a6c85

francesca64 force-pushed the super-dpi branch from 00fdefd to 68a6c85 Compare June 14, 2018 16:09

francesca64 added 2 commits June 14, 2018 12:31

Improved DPI factor sanity checks

2217306

🎉 Documentation 🎉

28c862b

francesca64 changed the title ~~[WIP] DPI for everyone~~ DPI for everyone Jun 14, 2018

francesca64 merged commit 1b74822 into rust-windowing:master Jun 14, 2018

nixpulvis mentioned this pull request Jun 15, 2018

High DPI scaling factor/Wrong monitor dimensions alacritty/alacritty#1378

Closed

elinorbgr mentioned this pull request Dec 6, 2018

High CPU load when moving window between monitors #706

Closed

iceiix mentioned this pull request Jan 14, 2019

Emscripten support broken: missing function: emscripten_set_mousemove_callback / assertion failed: validate_hidpi_factor(dpi_factor) #760

Closed

This was referenced Jan 23, 2019

Not using high DPI sciter-sdk/rust-sciter#49

Open

Blurry window on Windows and HiDPI displays andlabs/libui#184

Open

elinorbgr mentioned this pull request Apr 9, 2019

HiDPI scaling finetuning #837

Closed

yvt added a commit to yvt/ngspades that referenced this pull request Apr 25, 2020

Ngs.Engine.UI: Set the window minimum/maximum size based on the measu…

e16b89f

…rement This is finally possible thanks to the PR rust-windowing/winit#548!

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

DPI for everyone #548

DPI for everyone #548

francesca64 commented Jun 3, 2018 •

edited

Loading

elinorbgr commented Jun 3, 2018

francesca64 commented Jun 3, 2018

rukai Jun 3, 2018

francesca64 Jun 3, 2018

francesca64 commented Jun 3, 2018

rukai commented Jun 4, 2018 •

edited

Loading

francesca64 commented Jun 4, 2018

rukai commented Jun 4, 2018

francesca64 commented Jun 4, 2018

rukai commented Jun 4, 2018 •

edited

Loading

elinorbgr commented Jun 4, 2018

elinorbgr commented Jun 4, 2018

rukai commented Jun 4, 2018

kryptan commented Jun 5, 2018

yvt Jun 5, 2018

francesca64 Jun 5, 2018

francesca64 commented Jun 5, 2018

chrisduerr Jun 5, 2018

chrisduerr Jun 5, 2018

francesca64 Jun 5, 2018

francesca64 Jun 5, 2018

chrisduerr Jun 5, 2018

elinorbgr commented Jun 15, 2018

DPI for everyone #548

DPI for everyone #548

Conversation

francesca64 commented Jun 3, 2018 • edited Loading

elinorbgr commented Jun 3, 2018

francesca64 commented Jun 3, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

francesca64 commented Jun 3, 2018

rukai commented Jun 4, 2018 • edited Loading

Edit

francesca64 commented Jun 4, 2018

rukai commented Jun 4, 2018

francesca64 commented Jun 4, 2018

rukai commented Jun 4, 2018 • edited Loading

elinorbgr commented Jun 4, 2018

elinorbgr commented Jun 4, 2018

rukai commented Jun 4, 2018

kryptan commented Jun 5, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

francesca64 commented Jun 5, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

elinorbgr commented Jun 15, 2018

francesca64 commented Jun 3, 2018 •

edited

Loading

rukai commented Jun 4, 2018 •

edited

Loading

rukai commented Jun 4, 2018 •

edited

Loading