When attaching renderer-specific data, we need to
make sure that we key it off the renderer that is
in use, and cope with the absence of render data.
This fixes recording nodes in the inspector.
Return a pointer to the IconData struct. This is
closer to the glyph cache api, and will allow us
to add similar shortcuts. For now, just store
texture coords in the form we need, avoiding
converting them over and over.
This is a quick implementation that avoids many
glyph cache lookups. We keep an array of direct
pointers in the text render node, and throw those
cached pointers away whenever any atlases have
been dropped (since that may invalidate the cached
glyphs).
In many cases of the switch, we do not need the vertex data. This moves
the creation of the vertex_data array into a secondary function and only
calculates it the cases for which it is required.
We were putting big glyphs in the cache, in their
own texture, but forgetting to mark the texture
as permanent, so it could be reused, leading to
occasional misrendering. Fix this by marking these
textures as permanent, and explicitly freeing them
when the cache entry gets old.
Every few frames, we do extra work for the
cache aging. Arrange for the glyph and icon
caches to not cause extra work on the same
frame, to smooth things out.
There is no need for us to be very precise about
aging the glyph entries. It is enough to check
occasionally and mark old entries. This reduces
the overhead of work we do every frame on the
caches, at the cost of letting glyphs linger
a bit longer in the cache.
Make this function more similar to the icon
cache equivalent, and simplify it a bit. We
don't use the boolean return, and we don't need
to look at the age of entry when marking it
used.
Remember which atlases were removed, and only
check those when looking for icons or glyphs
to remove. For most frames, we don't have to
check at all since no atlases were removed.
Instead of copying the (rather large) RenderOp to the GArray, we can
simply set the fields directly in the allocated space for the struct.
In most cases, there wont be any allocations to make as the array size
is kept in tact across frame renderings.
We can just use memcmp here because even in the use of lookup keys with
C99 initializers, we can rely on any space between fields added by the
compiler to be zeroed. So we might as well use wider memory cmopares.
