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.
The Platform::*Application::Configuration class was split into
Configuration and GLConfiguration, the latter containing only
GL-specific configuration. Moreover, createContext() and
tryCreateContext() were renamed to create() / tryCreate().
There's now a constructor and a create() / tryCreate() overload taking
GLConfiguration and this will be later extended with VkConfiguration,
for example. GL-specific getters/setters from Configuration are now
marked as deprecated and merged into GLConfiguration during context
creation.
Everything has still hard dependency on GL, that will be done in the
next commits.
Proofread everything, make the packages the first choice (and manual
build only as a backup catch-all solution), don't force the users to
CMake but provide useful snippets to show how to use the libs from
CMake.
The move away from `nullptr` to NoCreate for constructing an application
without creating OpenGL context was done quite some time ago for
windowless application, but for some weird reason it was never done for
windowed apps. Now made this consistent.
The old `nullptr`-based constructor is still present, but marked as
deprecated and due to be removed in some future release.
As with Corrade, this is not exactly backwards compatible, but for
common use case without OBJECT libraries this should not be a problem.
In any case, recreate the build dir and update your copy of all
Find*.cmake modules to avoid weird things happening.
User-facing changes:
* Documentation of all Find*.cmake modules converted to
reStructuredText to follow official CMake guidelines.
* The newfangled way to use the libraries is to link to Magnum::Shaders
instead of adding ${MAGNUM_SHADERS_INCLUDE_DIRS} to include path and
linking to ${MAGNUM_SHADERS_LIBRARIES}.
* The old ${MAGNUM_*_LIBRARIES} are deprecated and now just expand to
Magnum::* target. Use the target directly. These are also enabled
only when building with MAGNUM_BUILD_DEPRECATED.
* The old ${MAGNUM_*_INCLUDE_DIRS} are removed as the Magnum::* targets
cover these too.
Internal changes:
* Global state such as include_directories() was replaced with
target-specific settings.
Vladimír Vondruš