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.
It's not like with SDL where we can't use <SDL2/SDL.h> due to macOS
packaged shipped without the SDL2 include directory.
This was just a bad copypaste from the FindSDL2.cmake module, probably.
On Emscripten this was equal to ";somebogusprefix" (as per the
toolchain), which got expanded into just somebogusprefix, losing the
empty string. Saving it back to CMAKE_FIND_LIBRARY_PREFIXES would cause
all subsequent find_library() calls to fail, because no library is named
somebogusprefixMagnum*.bc.
Thinking about this, the "somebogusprefix" was probably added "back
then" as a workaround to CMake complaining that I'm messing up in the
Find module. So I guess I can remove that as well.
Size of all executables got inflated by *half a megabyte* because of
this. I'm not sure if the change is worth it, so reverting for now.
This reverts commits
c01961ba6b5fb3f435ddfada6fba05
This affect virtually *all* targets so I would need to put this
everywhere, which I'm not. I am putting this only for the most often
used (and thus most problematic) dependencies, which is SDL and GLFW.
Vladimír Vondruš