The ambiguity with StridedArrayView1D<const char> was there always, I
just didn't hit that anywhere so far. With the recent changes in
Corrade, where StridedArrayView2D<const T> is constructible from
StridedArrayView1D<T> as well in addition to const T, the ambiguity gets
hit by a test. So test both variants and add an overload that resolves
those.
There's no other such case in either MeshIndexData or SceneFieldData, as
the StridedArrayView1D<const void> and StridedArrayView2D<const char>
constructor variants always have differing arguments. Neither it happens
in case of (ARM) platforms where char is unsigned.
Now it's less code, and it also no longer results in random edge
artifacts because the padding area wasn't correctly uploaded. I'm going
to do the same change in the FreeTypeFont and StbTrueTypeFont next.
Because otherwise the users likely have to do something similar on their
end to perform a texture upload etc., which means they'll either take
the easy path and upload everything including the unused area, or they
introduce various bugs in the process, leading to random artifacts,
especially when it comes to padding.
Which is exactly what I think is causing random test failures in the Ui
library text rendering, because the glyph cache filling process in
plugins is calculating the rectangle too tight, without considering
padding. Gonna fix that now.
Doxygen complains that it cannot find the \ce in there, heh. I copied
this from a `git stash show` view in Konsole, and SOMEHOW that thing no
longer copies the original text but inserts random newlines where the
terminal itself wrapped the text. Sometimes it works, sometimes not.
Code rot, code rot everywhere.
Will need those in the Ui library, in a form that's quite restricted
compared to what the generic shader provides (2D only, uniform
buffers always, ...). Plus it doesn't make sense to make the Ui library
depend on Shaders, so it would be just these two files copied verbatim
between the two.
I don't think that package was updated in any recent years, so it
doesn't make sense to show that in the README. ArchLinux or Homebrew
packages, which *are* maintained, aren't shown either, vcpkg isn't also,
so neither this should be.
The function got changed to return just two values instead of three in
7b5ef21bd9 (2018), yet the docs were never
updated.
Also clearly state the units in which row length / image height is
provided. This whole API is a mess tho, and a clear candidate for
deprecation.
The wording of the ARB_compressed_texture_pixel_storage requirement is
slightly different in Texture and such, likely due to being updated there
but not here.
And of course, besides the already-existing workaround for NV where it
reports size in bits instead of bytes, Mesa reports completely broken
pixel sizes in some cases. For DX1 I get 2x2 (?!), for ASTC 10x10 I get
1x1, which is basically unfixable.
I wonder how at all these utilities were used internally with success for
so long. Or were they never used because in every case I ended up
supplying the properties manually?
IIRC this still failed when I did the last changes to these tests in
October 2024 in e9b07ef4ce, so it seems
that the driver got fixed since. There are still the broken cases in
Texture3D tho, updated in the previous commit.
Not sure what was happening here, but my suspicion is that I took what
NVidia did with BPTC when used in 3D textures as the correct thing, and
then tried to shape the test around that. Or something.
Basically, instead of the blocks being 4x4x1 as the format says, the test
overwrote the pixel storage parameters to be four times larger 4x4x4
blocks, and then went with that, trying to shape the other test variants
to match that as well. And failing really bad, because it failed on Mesa,
and the only case where where it matched the (wrong) expectation was on
NVidia and only when the custom (wrong) pixel storage was used.
In all other cases this is called outside of #ifndef CORRADE_NO_ASSERT,
so this is likely some yet-undiscovered copypaste error. OTOH it's such a
corner case of a corner case that I don't think anyone ever hits that
because it'd fail on just anything else anyway:
GL::CubeMapTexture texture;
// nothing done here, not even a format / size specified
texture.compressedSubImage(...);
This extra call originates in ae70a62644
(2015, again) and was used in all places where DSA functions were called
directly without feature-aware dispatch. Since then, some of the cases
were turned into feature-aware dispatches, which means the call isn't
needed in those anymore, so I removed it. And to clarify why is it needed
in the remaining cases I added extra comments.
The uncompressed variant preserves the buffer contents if passed an empty
view, which was done in 5ee461bdbe (2015!)
but no corresponding change was ever done for the compressed variant. So
let's make both do the same, and actually test the code path, which
wasn't done until now either.
They got added in 6d41597d1d in 2018 to
selectively suppress a deprecation warning. But later on the deprecated
API got removed and these stayed, being useless. So just call the
ADL pixelFormatSize() APIs directly.
For compressed images the expected message was completely wrong, meaning
it'd fail in any case, and they were missing a SKIP on no-assert builds.
Then, for GL::[Compressed]BufferImage the assertions in setData() were
never tested at all.
Because there's no format that'd have more than 256-byte pixels anyway,
the theoretically biggest one would be RGBA64F or some such with 32
bytes. Nevertheless, an assert is now in place to verify the bounds as
well as ensuring the pixel size is not zero.
They're not parsed since 6b22a11170
(2020), so there's no point in keeping those workarounds. They're only
kept in utility application sources as they're parsed for pages, and in
tweakable implementations where it's easier to just copypaste the whole
ifdef expression from the header every time instead of modifying it to
not include DOXYGEN_GENERATING_OUTPUT.
Vladimír Vondruš