4.0 is from 2011, I think it's safe to assume that nobody really needs
support for anything older nowadays. Of course I can add that back if
needed, but I doubt anyone will ask.
In short this means the users no longer need to care about FindSDL2 etc.,
it'll just get done automatically. They don't need to drag along
FindMagnum / FindCorrade anymore either, but having them gives a much
more reasonable error message if the library cannot be located at all, so
I still recommend having them.
This is just documentation-facing, instead of documenting an overload as
having a default-constructed argument simply show just one constructor
with a default value.
Also simplify the wording. They either create an OpenGL context or not
(or not implicitly).
Similar to the change done in Corrade, see the commit for details:
878624ac36
Wow, this is probably the most backwards-compatibility code I've ever
written. Can't wait until I can drop all that.
With this flag set (which is done implicitly for all windowless apps
and, conversely, not done for all windowed apps), the default
framebuffer state isn't touched in any way, which should avoid potential
race conditions with default framebuffer on another thread.
This removes one unnecessary allocation from each application startup.
In some cases of the windowless apps the Platform::GLContext could be
put directly into the class, in other cases it had to be wrapped in an
Optional because we need delayed construction and/or earlier
destruction.
Disabling engine startup log or modifying enabled extensions /
workarounds from the application side was one of the common pain
points and this should *finally* solve the problem. This Configuration
is now inherited by the usual Platform::*Application::GLConfiguration /
Platform::Windowless*Application::Configuration classes people are used
to, so for the end user it's just as if these classes got a bunch new
options.
Having this, I also extended the ContextGLTest to verify that the
Configuration and command-line options do what's expected because that
hadn't automated tests until now. The test is mostly a copy of what I
did for Vulkan already, nothing special. Additionally all
Platform*ApplicationTest executables gained a new --quiet option to
verify that the GL::Context::Configuration subset gets correctly passed
from the Application code, because that's something we can't really
verify in an automated way.
Should make new things more discoverable, avoid confusion when a
documented API isn't there and reduce the need for maintaining multiple
separate versions of the docs.
Deprecated for 2018.04, it's been almost a year since. Whoever is using
Magnum regularly updated already, and who not can always upgrade
gradually (2018.02, 2018.04, 2018.10, 2019.01 etc.).
Same as windowSize(), it's there now just to make the ported examples
compile at the moment. Will need to be replaced with proper
implementation later.
With HiDPI support it's no longer just about window size changing -- if
the framebuffer size is different than window size, on resize both are
changed to new (different) values. Other than that, for example, when
moving a window from one display to another with a different DPI,
all three of window size, framebuffer size and DPI scaling can change as
well. This should be all reflected in the event.
This change is done in all Application classes, but the full
implementation is only in the SDL2 implementation at the moment, as the
others don't have full HiDPI support implemented yet. The old
viewportEvent(const Vector2i&) is deprecated and for backwards
compatibility called with either framebufferSize() or windowSize()
(depending on level of HiDPI support) from the new event. Overriding the
old one will still work as expected (in case you build with
MAGNUM_BUILD_DEPRECATED enabled and use the `override` keyword -- which
you should); overriding the new one will cause the compat implementation
to not be called anymore.
In order to make it possible to preserve backwards compatibility, the
viewportEvent() is no longer pure virtual in Screen. That's also
consistent with all Application implementations.
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.
Vladimír Vondruš