Counterpart to GlyphCacheArrayGL. At first I expected that it'd need
TextureTools::DistanceFieldGL to be expanded with texture array support
but after enough massaging of brain matter I realized that not really,
since the procesing has to be done slice by slice anyway, and having to
upload the whole array just to have a temporary input for processing
would be a waste of memory.
At first I was like "ugh this is BAD" and made the texture and output
framebuffer resident. Then I realized that for the upcoming array
variant I need to reattach the output texture every time, so having a
resident framebuffer was not that useful anymore, and then I realized
that having a resident texture but calling setImage() on it is not any
better than making a temporary one every time, and making the resident
texture significantly larger just to accomodate any size that could
possibly be processed was even worse. So, ultimately it's just these
comments.
Right now it didn't really matter as the only subclass making use of
this was DistanceFieldGlyphCacheGL in which the processed format was
always R8Unorm, nevertheless it's better this way, and makes it work
with 16-bit output and such that might get added in the future.
There's really no need to allocate 56 MB of image *and* texture data
just to verify the constructor is called. This makes the Emscripten test
OOM and there's really no need for that.
Was postponed in 8168a06bab because the
needed DebugTools::textureSubImage() was not there yet. Now I have (a
simplified version of) it done, so use it.
Same approach as done e.g. in the Ui library -- taking advantage of the
base class already allocating an internal state struct, deriving from it
and putting the state there instead of either having it as a class
member (at the cost of extra header dependency) or as a separate state
struct (at the cost of extra allocation). The only downside is a virtual
destructor in the state struct, but compared to the alternatives that's
completely fine.
One obvious use case is rendering a text that's just a bunch of \n
characters. With the current code, it would result in a completely empty
rectangle no matter how many newlines there would be, which isn't right
because -- even if nothing is actually visible -- it would break
anything that relies on the bounding rectangle for alignment and
positioning of other content.
Another case is for example the Ui library, which -- once ported to
use the new Renderer instead of the lower-level APIs -- wants to use the
bounding rectangle for cursor and selection positioning. And if it would
be empty for empty text, it'd mean empty input boxes would have
invisible cursor. Not good.
The old Renderer implementation seems to have handled this correctly --
but in f3d6ab4916, when porting to the new
APIs, I discarded that from the test, thinking it was some unnecessary
behavior. It wasn't, it was just never tested directly so I forgot it
was needed.
The tests all pass exactly as they did before, apart from slightly
different assertion messages. I moved the guts from Renderer.cpp to
RendererGL.cpp as the code relies on both GL and STL, to not have it
spread over too many places.
Apart from the fact that it blew up when the text was indeed empty,
which is fixed now (ugh), it was kinda obvious with the current
implementation but won't be when the guts get replaced with something
reasonable. So ensure we don't break existing use cases.
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.
So far the Renderer doesn't work with that, and neither the builtin
Vector shaders are be able use it, but gotta start somewhere.
I wanted to have the texture contents tested on ES, but it turns out
that implementing DebugTools::textureSubImage() for arrays is blocked on
another feature I badly need to finish first. Sigh.
One was a Doxygen workaround that shouldn't be needed anymore and an
API reference missing from e1c9c4d007, the
other was an inconsistency in a test that was just weird but shouldn't
affect anything.
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.
Vladimír Vondruš