I have no idea what is gping on in the JS land and why there's always 76
ways to do a certain thing, but since everything else in this file is
accessing members via `module.` and not `this.`, these variable accesses
likely should do the same.
Funnily enough the comment next to the relevant test case said that
"Left is the default, thus should result in no shift" AND YET right
after there was a shift of -10.0f. Done in the original commit in
568a4205a6 (2023) already, and I don't
remember what was actually the intent.
The glyph offset *is* discarded if GlyphBounds is specified, as that
might still make sense in certain contexts.
A glyph offset is non-zero usually for combining characters, with
regular base characters it's rare. It might however be useful for icon
fonts for example, where narrower icons might have an extra offsets to
make them visually align with wider icons when put underneath each other
and aligned to the left.
Same as what happened with GCC 6.1 for math types already, version 16
with optimizations enabled is apparently able to "see through" the
NoInit constructor and discard whatever happened on that placement-new'd
memory before. Eh whatever, I just wanted to verify that *I* am not
accidentally zero-initing the thing.
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.)
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.
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.
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.
By now I tested on GCC 4.8, various Clang versions, most MSVC versions,
building the library was without warnings on all those, and so I
expected newer GCC to be also silent when it should be. Nope. Ugh.
I wanted to just ignore these, but the RT builds for some reason have
warnings-as-error enabled by default and, UGH, I just want this thing to
finally pass the CI.
Not only the implementation is a template hell full of its own problems,
the internals are also just wrapping trivial bits of STL without adding
anything of value on top, so ultimately any code that actually used this
thing ended up being slower to build, more verbose, harder to reason
about and with thousands of tiny little inefficiencies all over the
place. So let's just finally say no to this idea from 2012.
"These seemed like a good idea at the time." But that was in 2013 and
while that might have been acceptable back then, it's not anymore, it's
all just a complex abstraction that prevents any reasonable resource
reuse and forces a dedicated draw call for each use.
Just do this directly from the corresponding Primitives instead.
Deprecating those allows me to eventually deprecate the (also
overengineered) ResourceManager class, at which point Magnum should be
finally free from the worst design decisions from 15 years ago.
Unfortunately several examples still rely on it (while it only makes
them more complex, not better), have to wait until those are cleaned up
first.
Vladimír Vondruš