Don't try to look for them if we don't use them. It only makes people
install additional outdated crap on their machines for no reason. The
only case where platform-specific GL headers are needed is in case of
iOS which doesn't provide any means of function pointer loading, but
there the include is passed implicitly from the framework.
Emscripten's MINIMAL_RUNTIME requires -lGL or -lopenal to be specified
(the default does that implicitly). It doesn't hurt to do that every
time and it makes the Find modules slightly simpler.
If building with deprecated features enabled, the buildsystem checks if
the option is still set and is inconsistent with what Corrade reports
and reports a deprecation warning. For backwards compatibility the
MAGNUM_BUILD_MULTITHREADED CMake variable and preprocessor macro are
still provided as well.
Well, only for CMake 3.13 and newer, by using the SHELL: variant of
INTERFACE_LINK_OPTIONS. In order to stay compatible with older versions,
it needs to be done in FindMagnum.cmake and modifying the global
CMAKE_EXE_LINKER_FLAGS. This case was updated to work properly also with
CMake subprojects.
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).
Vladimír Vondruš