Before this commit, all reexported symbols were displayed as if they
were part of `glyphon` directly. Users not being able to see at a glance
what's part of which crate has a few disadvantages. It makes
understanding the whole stack more difficult, since it's unclear what's
part of the wgpu-integration and what's part of the general text
handling. Personally, I also think this can deter people from using
glyphon as this makes the crate (which is "just" the wgpu integration)
seem huge. Finally, some symbols in the docs were not linked (as if it
was private), which is also really bad for browsing docs.
The latest `cosmic-text` release performs bucketing calculations after
layouting. This allows us to provide proper subpixel offsets, as well as
scale any buffer thanks to its linear layout properties.
See https://github.com/pop-os/cosmic-text/pull/143.
The `TextAtlas` will have an initial size of `256` (we could make this
configurable) and `try_allocate` will keep track of the glyphs in use
in the current frame, returning `None` when the LRU glyph is in use.
In that case, `TextRenderer::prepare` will return
`PrepareError::AtlasFull` with the `ContentType` of the atlas that is
full. The user of the library can then call `TextAtlas::grow` with the
provided `ContentType` to obtain a bigger atlas (by `256`).
A `TextAtlas::grow` call clears the whole atlas and, as a result, all of
the `prepare` calls need to be repeated in a frame until they all
succeed. Overall, the atlas will rarely need to grow and so the calls
will not need to be repated often.
Finally, the user needs to call `TextAtlas::trim` at the end of the
frame. This allows us to clear the glyphs in use collection in the atlas. Maybe
there is a better way to model this in an API that forces the user to
trim the atlas (e.g. make `trim` return a new type and changing `prepare` and `render` to take that type instead).
Instead, issue a `write_texture` for every glyph that isn't present in
the atlas. I think this should be fine, since cache eviction should be
rare and, therefore, uploads will be too.
The result here is lower memory usage for bigger caches.
I noticed that the `RecentlyUsed` map was actually a `RecentlyInserted`
map. This caused panics when trying to reduce the initial texture atlas size and
dynamically increase it (coming in another PR!).
