switch winit size to logical to be dpi independent

[mockersf]

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.

[ambeeeeee]

Gotta love DPI

[cart]

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]

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:

• run with cargo run, and you get a small window has it follow the screen dpi
• stick the binary in binary.app/Contents/MacOS/binary and winit will report a scale factor of 1.0, as it need a specific entry in the Info.plist to be dpi aware and that's not enabled by default (https://developer.apple.com/documentation/bundleresources/information_property_list/nshighresolutioncapable probably but didn't try)

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]

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.