DPI problem umbrella issue

[icefoxen]

Overview of issues:

• Winit integration tracking #391
• Correct handling of DPI related information unrust/uni-app#4
• Highdpi is awful. rust-windowing/winit#796
• HiDPI scaling finetuning rust-windowing/winit#837

Demonstration:

• https://github.com/icefoxen/heckin_dpi (uses ggez 0.4 to demonstrate aliasing with and without pixel information)

Mac-specific problems:

• OS X 1/4 window size viewport after toggling fullscreen #409

Issues reported due to DPI being incorrect (some SDL, some winit):

• [question] spritebatch, stripes between images #616
• Wrong scaling when drawing #535
• Creating context fails with "glxSwapIntervalMESA failed" #294
• Can we have pixel-based sizing for fonts? #268
• Crisp text #263

Maybe related? The Mac OS Weird Screen Size Problem:

• Bad screen offset on MacOS #553
• Scale starts correct then becomes wrong #539

[icefoxen]

@icefox Hmm, does retina work for ggez on macOS? 
The reason I ask is because I can't see where winit sets NSHighResolutionCapable - searching for that in the repo yields zero results.

Which makes me wonder if ggez has retina support on macOS since you use winit?
afaik NSHighResolutionCapable can't be set programatically

[seivan]

@icefoxen The only thing I'm not sure of is if NSHighResolutionCapable is a strict requirement but as of now, I can't get retina (scale factor 1.0) when letting SDL2 setup the window and the Metal Layer.

[icefoxen]

Found some pretty good references on OSX stuff: https://developer.apple.com/library/archive/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/APIs/APIs.html#//apple_ref/doc/uid/TP40012302-CH5-SW2 . Rummage around other things in that section for more info.

I like how they explain their reasoning on why you should never need to use the various tools they give you. It all makes perfect sense if a) pixels are actually invisible, b) it always works the same across every device (and OS), c) Retina displays never get bigger or smaller, and d) you never care about degenerate cases like aliasing or moire effects because e) OSX's Magic Drawing Hints fix everything for you behind the scenes. Unfortunately, the real world is seldom this tidy.

I'm not bitter, honest.

[hughlang]

Please see my latest comment on #553. I spent enough time with this to feel like I can help out. And I can test on mac, linux, and windows. Thanks.

[icefoxen]

@hughlang I'd love some help, thanks! Sorry for the delay in getting back to you. This is definitely something I'd like help with, it's just tough 'cause I'm so frustrated with it I can't stand to try to deal with it more than once every three weeks apparently. :-P

[hughlang]

Thanks! I researched other projects that had a similar hidpi problem. I found this to be a little relevant:

https://github.com/PistonDevelopers/glutin_window/pull/149/files

It seems like they ditched hidpi checking in favor of the to_physical() method call. Maybe the nonsense of hidpi is now fixed upstream.

[icefoxen]

It's implied to be fixed in the response to rust-windowing/winit#796 but I just haven't had the time to dig through and see how complete and comprehensive the fix actually is. If winit provides a nice way to actually give us real resolution numbers, we should use it everywhere necessary.