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.
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.
Sometimes it's desirable to just make a mesh indexed unconditionally,
which wasn't really possible with this thing, and having to special-case
that at the call site is very annoying. Now it makes a mesh
trivially indexed if it has any other primitive than the ones listed,
and if it's already indexed, it's just passed through.
Following the spirit of extension-based functionality, the entrypoints
are available always but do something (i.e., call the actual WebGL API)
only if the extension is advertised. Which it is only on Emscripten
3.1.66+ because older versions don't have the corresponding entrypoints,
so there it's marked as disabled.
Additionally, EXT_polygon_offset_clamp is now also working on 3.1.66+,
but there's no wrapper for it yet.
So the users don't accidentally create an instance with the processed
format / size being different only to get greeted by a nasty bounds or
format assertion inside flushImage() / doSetImage().
Now it's only allowed to be done by a subclass (such as
DistanceFieldGlyphCacheGL, or, ahem, MagnumFont), and doSetImage()
additionally has an assert to notify the implementer that a subclass
needs to provide its own override.
This also feels kind of messy, honestly. It's as if the
DistanceFieldGlyphCache should never have been a subclass, maybe?
Now, instead of accessing the texture directly, it uses the public
setProcessedImage() API. For which it needs to subclass the cache in
order to advertise ImageProcessing, which means the class can no longer
have the implementations private.
I don't really like this, ideally none of this would be needed and
MagnumFont would implement fillGlyphCache() instead. Not sure how to do
that yet tho as there's still the issue with DistanceFieldGlyphCacheGL
being RGBA, so this is a half-assed solution until a better one is
found... or the plugin gets ditched completely.
They don't have anything specific to DistanceFieldGlyphCacheGL and on
the other hand contain special-casing for Luminance vs Red on ES2 that's
specific to GlyphCacheGL internals.
Additionally, in DistanceFieldGlyphCacheGL the code could assume that
the pixel format is either R8 with EXT_texture_rg present or RGBA8
without, here it has to check for EXT_texture_rg presence as
GlyphCacheGL can use R8 even without EXT_texture_rg.
Vladimír Vondruš