Cull glyphs fully outside the bounds, and clip glyphs intersecting the bounds. This is all done on the CPU for now.

Fixes #2

We'll wait on a new version of fontdue to be published before merging.

I have Separated the Source into files which should improve source Readability. I have Removed and Replaced the Error Enums with a single Enum using ThisError to also allow handling WGPU and such Error for later usage if you expand to more features that needs wgpu error handling.

This allows the glyph cache to be shared between renderers.

Fixes #6

For now, we also reuse some other fields where possible (e.g. params, bind groups). We could change this later if we'd any of these to vary between renderers.

This doesn't change the storage, so a single 2D texture is still used for now.

Some other ideas:

• We could empty the cache easily if we had an Arc per glyph to know if it needs to remain in the cache. This would probably be really heavyweight and we'd need to change the refcount per glyph every time prepare is called, so I avoided this approach.
• Pass layouts into render and verify the glyphs exist instead of storing them in a Vec on TextRenderer. I didn't do it this way because layouts can change between prepare and render, although maybe we could require that it's not allowed (e.g. through documentation or lifetimes).
• We could generate an atlas internally if we don't want to require the atlas to be passed in explicitly in all new functions (e.g. builders or Default). This would make the shared atlas opt-in but it seems like we'd probably want the opt-in behavior by default.
• We could accept &mut TextAtlas where we need to use the atlas instead of internally storing Arc<RwLock<InnerAtlas>>. This avoids Arc and RwLock to be replaced by something else (e.g. Rc when running single-threaded). Doing it internally seems to have better ergonomics because we don't have to pass in &mut TextAtlas all the time, but there's a good argument for keeping this external too.

Allows either &[layout, overflow] or &[&layout, overflow]

Discussed in https://github.com/grovesNL/glyphon/issues/1#issuecomment-1286428829

So in small or large projects it does tend to be a good Idea to split structure and data types into their own parts. This makes certain things Easier to find and can improve readability and Adaptability. Keeping most of everything in a Single file generally is a huge turn off to programmers who are willing to help as it makes it harder to find Certain things. This is just a Suggestion not really a Must do.

TextAtlas and Text Renderer can be split into their own files. The major Data structures at the top Could either Stay since they are small or be moved into a single separate file to remove code form the lib.rs. Some internal Changes Could also be split into Functions as well and just made inlined, which can make Code easier to read if the function names Make sense for what it does.

Splitting up the Code can also help later on with new Feature Additions to this library. Anyways What do you think?

Hey, I like that this is using the latest shader format. You might want to add this to Cargo.toml or make mention of it:

[patch.crates-io]
wgpu = { git = "https://github.com/gfx-rs/wgpu" }

Ideally we could have an easy way to have multiple text renderers that share the same atlas to avoid extra texture allocations and share glyphs when possible.

We could do this by passing the atlas to prepare, sharing internally, etc. Alternatively we could share a text renderer between all layers, and the text renderer could model layers directly somehow.

Better support WebGL by padding uniform block to 16-byte alignment, which will usually cause the block size to match UNIFORM_BLOCK_DATA_SIZE on WebGL.

We might be able to remove this or handle it differently eventually depending on how it's supported upstream.

(see https://github.com/gfx-rs/wgpu/issues/2072#issuecomment-1147599245 for more context)

Removes the internal RwLock in favor of accepting &mut TextAtlas (follow-up from https://github.com/grovesNL/glyphon/pull/9#issuecomment-1137501663)

Handle text overflow outside of layouts through culling and clipping.

Culling:

• We could cull on the CPU, e.g. if all or any glyph's vertex is outside the layout then we could skip it
  • We could also clip on the CPU at this point if we want, see note below

Clipping:

• When one layout is used per render, clipping with scissor could be handled outside of glyphon or by glyphon setting the scissor
• When multiple layouts are used, we'd probably need to handle clipping through shader discard or clip on the CPU (e.g. clip the vertices and sample the glyph from the remaining area)

Consider handling scale, shear, rotation, etc., at least for typical 2D use cases

Also related to #3 because pixel snapping wouldn't work well depending on the transformation.

Currently we snap to the nearest pixel so kind of avoid this.

We probably want to have a strategy for handling subpixel positioning and AA generally. This can be difficult with glyphs because we might need to generate multiple glyphs for various subpixel positions.

It's a bit difficult to organize fonts/layouts and pass them to renderer.

Consider some other way to handle fonts, layouts, etc., possibly wrapping all of fontdue to remove fontdue from the public API.