The data are immutable by design, so it's a special "move constructor".
Usable when a plugin in proxying image import to external importers
(such as AnyImageImporter) and wants to attach its own state to the
result.
Last missing piece for fully orthogonal functionality. There was a
lerp(T, T, BoolVector) before, but not a scalar version. This also makes
scalar interpolation phase in select() working with arbitrary types.
Doesn't make any backwards-incompatible change -- plugins can still
export the transformation as matrix and users can still access the
combined one even if separate transformations are used. Yay!
Removes all needless private static class members and fixes a bug
introduced when getting rid of the global window pointer -- the user
window pointer was set only in the case of having a GL context, not in
the contextless case. Boom. (This bug happened after 2018.04, so I'm not
putting that in the changelog.)
The change done in 680144f1c5 was not
properly handling these cases:
* Mesh(NoCreateT) and wrap() were not constructing the internal vector,
which blew up when move-assigning another instance.
* ~Mesh() was not destructing the internal vector if the VAO ID was
zero or non-owning wrap() was used.
Strangely enough none of these were causing *any* problems for me on
Linux (even ASan was totally quiet and due to the unfortunate
combination of bugs even when I assigned totally random data to the
storage vector). This however blew up on MSVC, assuming there the
implementation is more checked.
Because it's possible to construct Mesh with no GL context available,
the move construction and destruction needs to avoid accessing Context
unless really necessary (it would be also unclear which type of vector
should be constructed if we have no context).
Extended the tests to handle hopefully all the cases.
Much easier to write (and explain!) than Shaders::VertexColor2D::Color{
Shaders::VertexColor2D::Color::Components::Three}. Ugh. Why again it
took me *years* to realize?