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!
Microsoft should fire all versioning scheme managers and then start
over. Why a single product needs
- a marketing version that's just a year number
- a major.minor.patch marketing version because the year was too coarse
to be meaningful for anything, and that version being also completely
unrelated to the year for good measure
- a runtime library version that used to match the major.minor marketing
version a decade ago but then it somehow got out of sync
- a _MSC_VER macro that was in sync with the short marketing version
last time in 1989 and never again
- an internal build number that feels like a countermeasure to "sorry,
can't have reproducible builds so be sure to ship the artifact number
194033811, that one we tested"
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.
Other (development) packages don't need this as they disable
makepkg-supplied buildflags altogether.
Co-authored-by: Konstantinos Chatzilygeroudis <costashatz@gmail.com>
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.
It now delegates to Assimp for ASCII files, along with StlImporter that
does the same but was already marked as having minor caveats. Better
than nothing, and it's not my problem that Assimp leaks and crashes like
mad on broken files.
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.
Vladimír Vondruš