* Remove `Arc` around `RenderPipeline`
It is not necessary anymore in last `wgpu` version.
* Replace `RwLock` with `Mutex`
It was only used for writing.
* add support for svg icons
* remove SVG helper struct
* forgot to remove default features
* rework api for custom glyphs
* remove unused file
* expose custom glyph structs
* remove `InlineBox`
* use slice for TextArea::custom_glyphs
* offset custom glyphs by text area position
* remove svg feature
* remove unused file
* add scale field to CustomGlyphInput
* update custom-glyphs example to winit 0.30
* fix the mess merge conflicts made
* add final newline
* make custom-glyphs a default feature
* remove custom-glyphs feature
* remove unnecessary pub(crate)
* rename CustomGlyphDesc to CustomGlyph
* rename CustomGlyphID to CustomGlyphId
* improve custom glyph API and refactor text renderer
* rename CustomGlyphInput and CustomGlyphOutput, add some docs
* Support sharing `Pipeline` state between `TextAtlas`
* Keep using `Vec` for pipeline cache
* Use `OnceCell` to keep `Pipeline` private
* Revert "Use `OnceCell` to keep `Pipeline` private"
This reverts commit 4112732b1734a3bb6b915d2103e699ef549b77c1.
* Rename `Pipeline` type to `Cache`
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!).
