This was fixed in GLFW 3.3.7, released in 2022. As with the workaround
removed in the previous commit, it isn't reasonable to keep old patches
for functionality that used to be broken but is long fixed upstream.
IOW, if you're hitting this bug, either update GLFW or downgrade Magnum
to a version before this commit.
094aa6d3c7
This reverts commit c8d2c33ac6.
Back in 2019 this got hit in only one very rare case, and was fixed
in GLFW 3.3.1 in 2020. Now, with virtual DPI scaling being the default,
physical scaling is almost never used, and the chance that someone is
still on X11, suffers from this XRandR bug, explicitly uses physical
scaling and is on never-since-updated GLFW 3.3.0, is basically zero.
Yet, I'm adding an assert so it shows up something more reasonable than
a division by zero error, and in the rare chance someone actually *does*
hit that assert, they can work around it with --magnum-dpi-scaling 1 or
equivalent either via an env var or directly through code.
This reverts commit 411e349358.
In 6ab321a38c (2023) I made a change where
the DPI scaling value is queried every time it's accessed and nothing is
cached, matching what's done with window and framebuffer size. However,
a consequence of that is that (on Linux at least) the whole complexity
of querying and calling X11 symbols is then re-run each time a DPI
scaling value is used, which in certain use cases may be several times
per frame. And if one is running Wayland, or hitting any of the other
corner cases that produce a warning, it causes endless log spam in the
output. Sorry, that wasn't a good idea.
Now the value is cached again, and explicitly re-queried on each window
size change, with log output suppressed to not repeatedly spam the same
warnings. Which should solve the original issue why the changes in
6ab321a38c were done at all, but without
the downsides. The documentation of dpiScaling() was also still saying
that the value is only available once a window is created (which wasn't
true until now), this commit reverts back to that.
Furthermore, in case of Emscripten, the DPI scaling is only depending on
configuration and/or URL arguments specified upon startup, thus the
value can be simply just cached forever without having to recalculate
it. What changes there instead is the device pixel ratio, which gets
re-queried each (browser) window size change.
As was the case in Corrade, this was due to an extra `static`. Except
for the warning in the snippet file, where I don't see any other way how
to suppress it.
This partially reverts commit b8bddc438c.
Except for the FoV-taking overload, which calls tan() inside, and which
is constexpr only on C++26, so likely not in all STL implementations
just yet. (And I don't have a CORRADE_CONSTEXPR26 macro yet either.)
Same change as in Corrade, additionally reflected also inside
FindMagnum.cmake for reuse by depending projects. Besides moving closer
to the "standard" way of doing things, using this module allows me to
drop the custom logic around LIB_SUFFIX, as the /usr/lib vs /usr/lib64
etc. distinction is now handled by GNUInstallDirs along with any other
variants.
It warns inside <type_traits> for some reason. Happens on Emscripten
5.0.2 all the way until latest 6.0.3, didn't happen on 5.0.1, and the
random Clang revision it's using isn't even released as a version 23 yet
so I can't tell if this is specific to Emscripten's filesystem layout or
is something that'll happen when building natively as well. So just omit
those few for now.
The <emscripten/version.h> header is now taken care of by Corrade's
configure.h, along with providing macro aliases for backwards
compatibility, so I can delete a lot of duplicated code everywhere.
Until now, if Magnum was found with, say,
find_package(Magnum REQUIRED DebugTools)
and then linked with
target_link_libraries(app PRIVATE Magnum::DebugTools)
the Find module correctly looked up also Corrade::PluginManager and
added it as a dependency of Magnum::DebugTools. However, DebugTools
themselves rely on the PluginManager only transitively, through Trade,
and dependency of Trade on the PluginManager isn't specified anywhere.
Which results in CMake happily putting CorradePluginManager earlier on
the linker command line than MagnumTrade, resulting in linker errors.
So instead the logic at the top is only used for finding the Corrade
dependencies, and the direct (non-transitive) dependency association
with a concrete target is done below, along with inter-Magnum-component
dependencies.
Looks like until now all find_package() calls included the other
transitive dependencies as well, so this accidentally worked. But for
example with the DebugTools reliance on SceneGraph and Primitives now
being deprecated, this may change.
And, exactly as expected, there's many cases that used the (implicit)
ValueInit while NoInit is a better choice. So yeah, minor speedups in
various places such as GL image download.
That's a too harsh behavior, as it'd break user code (instead of just
causing a bunch of warnings) when people update to a commit that
deprecates a new library.
Yes, I plan to merge audio import into Trade::AbstractImporter, but
until that's done, it feels silly to have to pay for the std::string
cruft given that it's present in just two arguments.
The code was splitting on just a whitespace before the changes in
95b3f8578d (2021), so I suppose I just
accidentally copied the same code over from handling the
--disable-extensions and --disable-workarounds arguments, where the user
*is* allowed to use any whitespaces.
And given that just a space worked well for over a decade before,
there's no reason to pessimistically expect the extension strings
suddenly include tabs or newlines.
All that work to reduce header dependencies and yet here it's full of
them, somehow.
Well, given the fallout in various GL tests now I wonder if I should
just chuck the rest along with the state allocation as a PIMPL.
This originated in 7ad928ae42 which looks
like a generic find & replace that removed all early return statements
because the unmasked renderer string on WebGL could expose both the
underlying driver (NVidia, Mesa, ...) and the wrapper (ANGLE, ...).
Ideally the compiler would warn about an unused expression, but
Optional::operator*() isn't const on mutable variables, so it didn't.
Only discovered this because I'm removing the Optional wrapper from this
member, and then the compiler started to warn.
Vladimír Vondruš