HiDPI support about orbtk

Why was this closed? I can't find an upstream issue you hinted at.

[jackpot51]

This is a good feature to implement. I am unsure where the features should go, that is, which library. My guess would be orbclient and orbfont

[FloVanGH]

orbclient and orbfont could be the right place, because then not only orbtk is benefits from HiDPI scaling.

[tangmi]

I tried out the orbtk examples on a macbook and noticed it didn't handle DPI scaling.

I think that orbtk and orbclient may need to both be aware of DPI scaling (orbfont, however, hopefully doesn't need to care, as orbtk can just request scaled font sizes to accommodate). I'll try and enumerate some of the things to consider when handling DPI, in case it helps orbtk in the future.

orbclient/orbtk_shell:

• Window creation: orbtk needs to be able to request a window sized in logical pixels and a framebuffer sized in physical pixels.
  • It looks like the way to handle HiDPI in e.g. minifb is to pass a buffer larger than the window size to update_with_buffer (emoon/minifb#50). I'm sure each window library handles this slightly differently, while some might not expose the functionality at all!
  • For the web, the canvas should be sized based on physical pixels and have a CSS size in "points" (rust-windowing/winit#1233).
• Window resize: orbclient/orbtk_shell would need to handle the dpi scale potentially changing as its own event and/or during resize. IIRC this is difficult to get right cross-platform without missing frames or jittering for a couple frames during the transition.
• Note that the DPI scale factor isn't necessarily a whole number and can go below 1.0 on the web.

orbtk:

• API coordinates: HiDPI scaling is just what happens when physical pixels and logical pixels are not equal, so we need to document which "pixels" each method takes (for user sanity, it should mostly be logical pixels).
  • Most user events/coordinates would be in "points" or "logical pixels" or "window pixels" (or whatever one wants to call it), which shouldn't pose much of an issue for existing users (I believe just redocumtening pixels to be points and adding DPI-specific APIs is how Apple initially transitioned devs onto the iPhone 4 retina screens.)
  • There should be some API to allow a stack of (image) resources at different scale factors and some logic for orbtk to pick the right one.
  • DPI scale factor needs to be queryable so that raw 2D/3D canvases can correctly handle different scale factors (alternately, raw canvases can apply a scale factor at the root and just really trust the rendering API to get it right)