As the time goes, I have less and less patience trying to figure these
things out. It's likely my fault for using the not-well-tested DSA APIs
or something.
For integer attributes, that is. This never worked and the MeshGLTest
even had an explicit test case for this, but it took me until now to
realize that this would be best caught at compile time. So now it is.
But since this functionality dates back to 2010, just removing the
values would likely break a lot of code (well, broken code, but still),
so the disallowed values are now deprecated, giving a compile time
warning when used, and are removed only on non-deprecated builds.
This warning isn't enabled by default by either -Wall or -Wextra, and
for a good reason. When I do that, it fires also for all uses of
Platform::Application, basically any subclass causes that warning to be
printed as well, even if given subclass is used just once, in an
anonymous namespace, and only through the MAGNUM_APPLICATION_MAIN()
macro. The only solution on Clang is to make such subclasses `final`,
but on GCC not even that helps and one is forced to really make the base
destructor virtual. Which doesn't achieve anything, only adds yet
another entry to the vtable.
So, in the SceneGraph it fixes one particular use case where the warning
was triggered, and since the fix isn't so invasive I'm fine with that.
For Platform I have no idea how an acceptable fix would look like, so I
hope nobody needs any of that anytime soon.
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102168, especially
the part saying "This warning should not be used.".
The views made it look like one cannot use Trade::ImageData etc. as
inputs, and the reason for using them was because there was a
load-bearing const in the view type that allowed slice() to work. The
slice() API is fixed now so this doesn't need to be silly anymore.
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.
This got deprecated in 069c81b9cb but
without any visible documentation bit, so it was almost impossible to
trace back to a particular version. Or know about it when using the API.
Back in 2020 when I wrote this I didn't really expect the MeshData to be
directly used for much more than putting them on a GPU, mostly because
that used to be the primary use case with the old MeshData2D /
MeshData3D. So the documentation was focusing mainly on populating a GPU
mesh, and any docs for CPU-side access were added rather hastily.
As now the asset processing use case is much larger, the original docs no
longer made sense. Let's hope this is better.
Not too great yet, but at least the most common operations have an
example snippet that shows real use, instead of jumping off a cliff
right into the most detailed description.
The more I looked at it, the more useless it felt. Also, since it's so
broken, I'm also completely removing it from the test because there's no
point in even testing it.
I attempted to make it private only to discover it was used by Magnum
Player to make the workflow with opt-in tweakable constants more
efficient. So let's document that.
Vladimír Vondruš