The distance reported by it is useless for any practical purpose because
it doesn't report a ratio of the current and previous radius between all
points, but rather the distance. Which, well, have fun using for any sort
of zooming.
(And yeah, given that the MultiGestureEvent is gone in SDL3, I spent
quite some time looking at what it actually did in order to reimplement
that functionality on my end, and it felt *extremely weird* to me that it
always considered just that single point, never the others in order to
calculate any sort of radius. This is why, because it never considered
any sort of radius between the points, so the "Multi" in there is highly
questionable!)
So this test is just to make the uselessness easy to verify, nothing
more.
Heh, somehow every time I run the full battery of tests I discover
another failure.
NVidia, with Vulkan version forced to 1.0 and when VK_KHR_maintenance1
isn't enabled, returns VK_ERROR_OUT_OF_DEVICE_MEMORY. So whitelist that
error as well and treat it as allocation failure and not a fatal error.
Not sure what I did in 3e4e1bde69 but that
updated XFAIL is now an XPASS on NVidia. Because, apparently, the clear
clears the whole memory, not just the image area, so even though the row
pitch is different, the comparison of the initial N bytes passes.
So I'm ditching the silly XFAILs and doing a proper image comparison that
includes the actual driver-dependent row pitch for the images. Finally,
the image-to-image copy was flat out wrong because it didn't take the
*input* row pitch into account, so it copied garbage and then compared to
a different kind of garbage.
Otherwise it may happen that the clock gets adjusted mid-frame, leading
to an underflow and an assertion like this:
Assertion _measurements[i]._movingSum + data >= _measurements[i]._movingSum failed at src/Magnum/DebugTools/FrameProfiler.cpp:233
The clock adjustment is known to be happening rather frequently under
WSL2.
The check for memory size was enough for llvmpipe, but not for
SwiftShader. And now it wasn't enough for NVidia either, so let's just do
it properly.
Ideally of course this would compare always. Don't feel like doing that
right now tho, so it's just a TODO.
This caused MeshToolsCompileGLTest to fail in a strange way, and
PhongGLTest::renderLowLightAngle() as well. Which looked rare enough that
I first suspected some random driver bug, but apparently it was all
caused by these using the default infinity range instead of explicitly
calling setLightRanges() on the shader.
The test is now updated to explicitly verify the default value when a
setter isn't called, to catch this problem better in case it reappears in
a different form elsewhere.
Neither of those are really critically important. Failure not being a
failure is fine (just don't make the shader broken in the first place),
multiple color output bindings should be in the shader source anyway.
This was quite a mess, the whole array name copypasted to each and every
access. I mean, yeah, originally I thought this would be *the* usage
pattern, but oh god this resulted in SO MANY copypaste errors.
Which ultimately means the two annoying NVidia failures in the
TextureGLTest related to pixel storage in compressed 3D images are no
longer failing as a result of cleanup.
A regression was introduced in 2a8e550b57
that affects only Windows builds. The version downloaded on the Windows
CI unfortunately doesn't contain CMake configs, so this went unnoticed.
I wanted to add this for GlfwApplication, only to realize the timer there
is a double, in seconds, so accepting *integral* milliseconds there felt
very weird. Let's use the fancy new time types instead.
Also updated the docs to (hopefully) clarify that setSwapInterval() has
to be called in order for the interaction between the two to work
properly.
As usual, the old variant taking untyped milliseconds is a deprecated
alias to this one.
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.
Before, if e.g. find_package(Magnum REQUIRED Vk) was called and the
installed Magnum didn't have Magnum::Vk enabled at all, it would still
try to call find_package(Vulkan) and do all other setup which could then
fail as well, resulting in way too many noise printed.
Now the decision about the _FOUND variable is moved all the way to the
top, and the actual target setup is only done afterwards.
Vladimír Vondruš