I'm not really sure if the extra work and link dependencies are worth
the warning, but since I *need* to do something similar for Windows, why
not have it here as well.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
Cameron Egbert