Allows the Font and FontConverter plugins be built without TARGET_GL
enabled. That was the last piece missing for making the magnum-plugins
repo completely GL-free.
This is already done in the FindMagnum module for both, but not in the
source tree -- for SDL2 it was done in the FindSDL2 module (seems a
strange place) and for GLFW nowhere. To make things consistent, I'm
doing that in the Platform CMakeLists now and removed it from FindSDL2.
Hopefully this doesn't break anyone's workflow (static builds of
SDL2/GLFW?). In that case we would need to re-add it to the Find
modules as well.
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.
Do the same also for other Unix-like systems except for Apple platforms,
where those dependencies are most probably satisfied by some frameworks
instead.
Yet again I merged too soon :/ b70ac5fa51
was not working for me at all -- on Arch the installed config file has
only one IMPORTED_CONFIGURATION, NOCONFIG, which wasn't propagated.
Besides that, there were some compiler definitions and other things that
*also* weren't propagated from the config file.
Reworked it totally in a simpler way, which doesn't work on CMake 2.8.12
anymore (but also who cares, systems that are stuck on 2.8.12 don't have
GLFW3 in repositories anyway).
Previously, when requesting OpenGLTester, the script correctly found
that it needs some Windowless*Application and a GL library and added
them as dependencies to OpenGLTester. But it didn't handle the
dependency of Windowless*Application on GL, which caused GL to be linked
*before* Windowless*Application, causing linker to complain that
Windowless*Application needs some more stuff from GL.
This will later enable conditional compilation of APIs that depend on
the GL library (for example the Text library directly producing compiled
meshes instead of just plain vertex data).
Statically built plugins get imported automatically when using CMake
3.1 and newer. Otherwise simply #include a corresponding
importStaticPlugin.cpp file.
Vladimír Vondruš