This is a replacement for the existing AbstractRenderer and Renderer2D /
Renderer3D classes, with no STL or other shittiness like excessive
allocations, and with a much better feature set. Deprecation of the old
APIs is going to happen next.
Compared to the old implementation it doesn't make use of the
complicated buffer mapping because -- unlike in 2012 -- such behavior
was since deemed questionable as the driver (or whichever translation
layer like ANGLE or Zink or Apple's GL-over-Metal) may still make a copy
anyway and doing so prevents buffer orphaning. So it's right now just
plain setData() / setSubData() calls. *If* it becomes some sort of a
bottleneck (which I doubt), I may reconsider, or add something else like
double buffering.
Builds upon RendererCore and generates index and vertex data from the
glyph positions and IDs. Documentation again coming later once
everything is in, next is a RendererGL which populates a GL::Mesh with
these.
A higher-level stateful wrapper around the low-level utilities, capable
of rendering text formed from multiple lines and multiple fonts. Will be
used as a backend for a new Renderer / RendererGL implementation.
No usage docs yet, those will come once the other two classes are made
as well.
I'm going to make a new Renderer class that's unlike the old one, and
isn't templated anymore either, so gotta make room for it first. I assume
that all existing code used the Renderer2D / Renderer3D typedefs so this
should be pretty much painless.
Ultimately this class will be gone, with only (then deprecated)
AbstractRenderer left, and Renderer2D / Renderer3D being aliases to it
-- internally it doesn't actually do anything dfferent, even the
positions are two-component in both cases.
The naming was adopted from CSS direction-aware alignment and it took me
quite a while to realize it feels alien, since everything else is using
"begin" and "end", not "start" and "end". So I'm renaming for
consistency.
These enums were originally introduced about 8 months ago but I don't
think anyone is using these yet, since they're not really advertised
anywhere and the existing to-be-deprecated high-level text renderer API
is so shitty that I don't expect it to be used for BIDI text and such,
at all. Sorry if you do, heh.
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.
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!
Especially given that nullptr causes an assert. All call sites basically
ended up passing a &font and all that extra annoyance just doesn't make
sense.
Given this API is still relatively recent, I'm not bothering with
backwards compatibility.
Which also allows the internals to be a bit simpler / potentially more
efficient, as the implementation can now access the glyph cache contents
directly, without a getter.
The new API makes it possible to alias storage for the glyph offsets,
advances and IDs (20 bytes per glyph) directly with the output positions
+ texcoords (16 bytes per glyph, times four) by splitting the retrieval
in two steps.
I wonder how long will it take before this bites back, heh.
In basically all cases it's two independent operations so forcing them
to be done together doesn't really bring any potential efficiency
advantages. On the other hand, splitting them allows allows the caller
to better make use of available memory, as the new
renderGlyphQuadsInto() allows the input and output arrays to be aliased.
Bumping AbstractFont plugin interface versions as this is a breaking
change.
The awful original STL-heavy public API is kept the same for now, it's
just the internals being now implemented using brand new APIs that are
actually usable with multiple fonts, font sizes and runs with different
scripts/languages/directions. There's also preparation for configurable
vertical text layouting, although for now the functionality asserts that
horizontal text is used.
This also makes Renderer.h header available on non-GL builds, as the new
APIs don't rely on a class full of GL objects anymore. The class will
get eventually renamed and moved to a dedicated RendererGL.h header, but
for now this partial update has to suffice.
So it's possible to shape the text even before having all glyphs ready.
That's one reason, second reason is that this is a more common behavior
-- it usually doesn't make sense to make the text jump based on whether
it's "zaxaca", "KEKEKE" or "yqpyq".
The original alignment based on glyph bounds is now moved into dedicated
`*GlyphBounds` variants. Additionally the `*LeftGlyphBounds` were
changed to subtract the initial glyph offset as well, `*Integer` now
rounds only in the direction where it's needed because a division by 2
happened, and there's a set of `*Bottom*` values that somehow weren't
there before.
It doesn't need to access anything else than what the base API provides,
doesn't render with it, and doesn't expose the instance via any getter
either.
Even though the Renderer is scheduled for a total rework and changing
the old API may feel like throwaway work, this change alone doesn't
break anything and allows me to test certain new corner cases.
All std::string arguments are now a StringView, what returned a
std::pair is now a Pair. STL compatibility headers are included on
deprecated builds to ease porting, as usual.
The only *really* breaking changes are in the internals, where an
ArrayView<const char32_t> is used instead of std::u32string, which is in
line with the change done in Utility::Unicode::utf32(); and a Triple is
returned instead of a std::tuple. Behaviorally nothing changed except
that fillGlyphCache() now asserts if the input string contains invalid
UTF-8 (which is also in line with the cahnge done in Utility::Unicode).
Partially needed to avoid build breakages because Corrade itself
switched as well, partially because a cleanup is always good. Done
except for (STL-heavy) code that's deprecated or SceneGraph-related APIs
that are still quite full of STL as well.
Instead make use of the ArrayView STL compatibility. To avoid breaking
almost all existing code the Corrade/Containers/ArrayViewStl.h header is
included implicitly when MAGNUM_BUILD_DEPRECATED is defined, but this
will get removed in some future release to speed up the compilation.
Allows the Font and FontConverter plugins be built without TARGET_GL
enabled. That was the last piece missing for making the magnum-plugins
repo completely GL-free.
103% of use cases use the returned value directly without checking, so
we might as well do the check ourselves. Added new function hasCurrent()
and added deprecated backward-compatibility conversion and -> operators.
Wow, that creeped to a lot of places.
Last dinosaur from the pointer age.
Vladimír Vondruš