Having it next to AbstractShaper didn't make sense, as there's various
use cases where font features are specified but the caller code doesn't
even know there's any shaper involved. Such as in the UI library.
Based on the actual text direction (either explicitly set or detected),
these resolve to either *Left or *Right. For the Text::Renderer it's
done automatically inside (and there's no way to actually set the
direction from outside due to the API being ancient and limited), for
the align*() utils the alignment has to be explicitly resolved using a
new alignmentForDirection() utility.
There shouldn't be any other values passed to these. Compilers, don't
even attempt to say that the alignment value is now maybe uninitialized,
I'm watching you!
This is going to get called from fillGlyphCache() that takes a string,
and thus should be better than one virtual call per character. The
single-character variant still stays, as it's a nice convenience API.
Eventually glyphSize() will get a similar treatment as well.
Expands the test added in 789c52fd8a, for
which a fix was done in 8f6f4053fc but
which forgot to handle the case where a buffer is unbound. The test now
fails with an invalid error.
This was already done for all application libraries and then also all
contexts in 1c6f77389d, was forgotten here
for some reason. A use case that may need it is a shared library shared
(heh) by multiple test executables.
This was due to the internal counter in the object being just 2 bytes,
which was made in order to optimize the Object class size. In practice
however, not counting the vtables, the class has SEVEN pointers and then
a transformation part that's in most cases multiple of 8. Which means
that on 64 bit platforms there was always 5 bytes of padding next to
this 2-byte counter and 1-byte flags, thus no reason to have it 2-byte
anyway.
On 32-bit platforms this *might* cause the Object to get bigger, yes,
but as it's heap-allocated it's more likely that it's put on a
16-byte-aligned address and thus occupying a multiple of 16 bytes
anyway. In any case, this won't really hurt, because the SceneGraph
situation is bad enough already due to all the pointer chasings and
overhead from loose allocations.
Took me quite a while to realize what was going on, but in retrospect
it's obvious -- the rasterizer just *rounds* the sub-pixel-positioned
glyph quads to nearest pixels. Which then can cause the neighboring
glyph data to leak to it (because the texture is then sampled not
directly on the edge pixel, but slightly outside of it), or it can also
cut away the edge, when it gets rounded in the other direction.
This was a problem with the original -- laughably inefficient -- atlas
packer as well, but because that packer had excessive padding around
everything, only the second edge-cutting artifact manifested, and that
one is rather subtle unless you know what to look for.
This means the packing is now slightly worse than before and sizes that
previously worked may no longer fit anymore. But since the new atlas
packer is relatively new (well, from September, time sure flies
different here), and the improvement compared to the original packer is
still quite massive, I don't think this is a problem.
And for Sdl2Application print both the keycode and keysym, as the
current way with a keycode seems different from what both GLFW and HTML5
does. But the SDL2 scancode also doesn't feel right because compared to
GLFW and HTML5 it swaps Y and Z on my keyboard. SIGH.
This all looked obviously correct so I never questioned it, but the spec
itself has the order mixed up for an unexplainable reason so it doesn't
match between MouseEvent and MouseMoveEvent.
In the Emscripten build, accepting events in EmscriptenApplication
prevents them from propagating further to the page, such as F1 that
would open a browser help page. That's not the case with SDL as SDL has
no concept of "accepting an event", so just document that in the test
code.
This is what both SDL and GLFW do, so it makes sense to be consistent.
Without it it's also impossible to handle keyboard shortcuts such as
Ctrl-C when editing text, which is rather silly.
Insufficient testing, sorry. This got broken after MAGNUM_TARGET_GLES3
deprecation in 87c7eea1e2, but the stupid
variable name was there before already, and it just worked for some
reason, but when the condition got flipped, setting *minor* version to 2
didn't do the right thing anymore. And of course, typical Emscripten,
it didn't complain at all in either case.
Took me an embarrassingly long time to spot what was wrong.
Vertex buffer offsets are like this already (and I already had a use
case with a mesh of size larger than 4 GB), with index buffers so far I
thought it's not needed, but it makes sense to do that as well -- there
can be a giant index buffer for many meshes and even though the total
drawn element count won't reach 1 billion (or 1 million, even), it can
still go over. Since it was internally already stored as a pointer-sized
value and some (but not all) code was treating it as pointer-sized, this
change just makes sense.
This also fixes "warning C4244: 'return': conversion from 'const
GLintptr' to 'Magnum::Int', possible loss of data" on MSVC, although in
a very different way.
Such as being able to print the contents as hexadecimal. Doing this just
for Vector and not any other math types, as those are all floating point
where it doesn't make sense. And for Nanoseconds, which are integers,
hexadecimal printing makes no sense either.
Got a suggestion that lerp() could be optimized to be one arithmetic
operation less. While valid in certain cases, it would break in case the
endpoints have wildly different magnitudes. Unfortunately that was only
my personal knowledge, not backed by regression tests. Now it is.
The change in 87c7eea1e2 caused a breakage
with old FindMagnum modules, which use if(MAGNUM_TARGET_GLES3) to decide
if they should link to libGLES.
This is now still only defined for deprecated builds, so non-deprecated
builds with old FindMagnum will fail.
Vladimír Vondruš