Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

switch winit size to logical to be dpi independent #947

Merged
merged 2 commits into from
Dec 1, 2020

Conversation

mockersf
Copy link
Member

Currently, when opening a window on a screen with high dpi, the window is smaller than intended.

With this fix, the window has the expected size on all screen.

Copy link
Contributor

@ambeeeeee ambeeeeee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotta love DPI

@Moxinilian Moxinilian added C-Feature A new feature, making something new possible A-Windowing Platform-agnostic interface layer to run your app in labels Nov 29, 2020
@cart
Copy link
Member

cart commented Nov 30, 2020

I agree that we should create properly sized windows on hi-dpi setups, but I also think we should discuss how DPI is handled from a UX perspective, as that will inform some of these changes. The approach in this pr "creates" new problems because any code that renders something now needs to be DPI-aware (if it doesn't want to be low-res / blurry):

  • The wgpu swap chain is now 2x too small on 2x dpi setups (which will be notice-able for 3d scenes)
  • The glyphs we generate for text are now 2x too small on hi-dpi setups
  • Some theoretical "user built render feature" will be 2x too small on hi-dpi setups.

I can think of two paths forward:

  1. The approach in this PR (report the logical size)
    • bevy code is "blurry" by default and individual features "opt in" to hi-dpi support
    • swap chain: multiply by scale factor
    • generated text glyphs: multiply by scale factor
    • this is the model winit encourages us to use (and seems to be pretty common in the hi-dpi world)
  2. "set" the window to a "logical size", but use/report the "physical" size by default
    • bevy code is "crisp" by default, but also "smalller than intended" by default
    • this would be a bit more honest from a "what resolution am i currently dealing with" perspective, but it then puts the burden on each widget to decide when to "scale up".
    • ui/text would probably just read the scale factor and scale itself up accordingly.
    • whether or not to scale sprites is probably app dependent
    • 3d works as expected automatically

(1) Feels like it has fewer "gotchas". Everything is consistent (and usable) by default and individual features need to be "special cased" to support hi dpi. Generally if you do something wrong, worst case scenario things are just blurrier. The downside is that by default users are no longer dealing with the actual resolution, which could cause confusion (especially when building rendering features).

@mockersf
Copy link
Member Author

mockersf commented Dec 1, 2020

This PR is probably not the complete solution, but I feel this is a good start that is important to have now.
I only have macs and high DPI screen and this has been my experience:

up to now, it's probably mostly an issue around packaging on macOS, and that's another issue that I hope to try my hand at soon (signing the app, placing the assets in the correct folder, icons, ...). There's probably something similar to do on other platforms.
anyway I'm now at a point where my game will render as expected on standard dpi, at the expected size on macOS no matter the dpi, and window size will change on windows/linux based on dpi

And in comes the webGL2 build. having the game change size at runtime according to dpi makes it very hard to embed in a page. I started doing that, and got reports that people were only seing a quarter of the game, as I did the page around based on how it looked on my mac, with a high dpi-smaller window game.

Anyway, all this to say that I think having the window always at the same size no matter the dpi is a better default than having the window change size following the dpi. I'm not completely sure how to go on from there to have features "opt in" to hi-dpi support, but that would be cool

@cart
Copy link
Member

cart commented Dec 1, 2020

Sounds like we're in agreement then. This pr seems like a step in the right direction. I'll probably follow up with swapchain / text fixes soon if nobody else does.

@cart cart merged commit 6b004f7 into bevyengine:master Dec 1, 2020
@fopsdev fopsdev mentioned this pull request Jan 24, 2021
@mockersf mockersf deleted the logical branch April 27, 2021 23:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Windowing Platform-agnostic interface layer to run your app in C-Feature A new feature, making something new possible
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants