Use the negative radius-scaled sine offset for the dividing plane,
matching the documented algorithm and sphereConeView(). The previous
sign rejected spheres that intersected the cone side near its apex
without containing the apex itself.
Add Float and Double coverage for near-apex intersections and misses,
including precomputed angles and translated and rotated cones.
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.)
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.
ICOM725