gfx_glyph integration redux #362
Conversation
`TextCached::load_fonts()` is no longer needed, as fonts created using `Font::new_glyph_font()` load themselves into the `GraphicsContext::glyph_brush` directly. This is possible thanks to new `GlyphBrush::add_font_bytes()`, which should hit release soon (making direct git dependency unnecessary). `Font::default_font()` and `GraphicsContext::glyph_brush` initialization need de-tangling.
The `Scale` is defined in the `Font` because, firstly, that's how existing API works, and I think it's very intuitive; secondly, from what I understand, having several copies of the same font at different scales is less computationally intensive than dynamically scaling the same font - need to benchmark that.
Not deadset on this, but it's a trivial enough change. De-tangled `glyph_brush` init and `Font::default_font()` - there's still duplicate data (I think), fully getting rid of that will require changing how `::default_font()` works and is used.
|
I think I've reached a point where I'll have to start adding (even more) code that's trivial and/or will be removed if we absorb It's functional as it is, though I'm not completely sure the transforms in Summary:
There are a few standing questions:
|
|
Sorry, took me a couple days to find time to take a good look at this. I like it. Only note, you should probably use On to pondering questions...
So what I'm imagining now is something that looks sort of like this... struct TextCached;
impl Drawable for TextCached {
fn draw_ex(self, ctx: &mut Context, param: DrawParams) -> GameResult<()> {
let text_params = param.into(); // Makes a TextParams with reasonable defaults where needed
self.queue(ctx, params);
self.draw_queued(ctx);
}
}
impl TextCached {
pub fn queue(&self, ctx: &mut Context, params: &TextParams) {
ctx.glyph_brush.queue(params.into());
}
pub fn draw_queued(&self, ctx: &mut Context) {
ctx.glyph_brush.draw_queued();
}
}I think this would let users both do the simple thing easily, and also access the full power of the API... a little like how |
|
Hilarious benchmark results, from here: https://github.com/icefoxen/ggez/blob/gfx_glyph_integration_too/examples/glyph_bench.rs . It draws 2500 copies of a single text object, either with the current
So, there's basically no reason NOT to use |
`TextCached` is now built from `TextFragment`s via `TextCachedBuilder`, invoked via `TextCached::builder()`, with a shorthand `TextCached::new()` that creates a `TextCached` from a single `TextFragment`. Not set on builder pattern: it's trivial to have `TextCached::new()` accept either single fragment or a vector of them, forgoing the need for a builder altogether. `TextFragment`s can be implicitly constructed from `String` or `(String, Color)` (more of these convenience implementations are trivial), and can contain color, font and/or scale information that will override that of their parent `TextCached`. This makes it possible to inline differently colored/sized/etc fragments (letters, words) into the text with dead-simple calls. When explicitly queued, `TextCached` now accepts a `TextParam` - a struct containing offset, bounds, color, font, and scale information (the latter three can be overriden by individual fragments, as mentioned). Offset dictates where the `TextCached` will be drawn relatively to `DrawParam::dest` specified in `TextCached::draw_queued()` (in screen coordinate units) prior to transforms - this provides the "rotation origin" that can't be specified in `TextCached::draw_queued()`'s `DrawParam`s due to unknown (better: unusable) size of the `TextCached`'s rect. Bounds allow `gfx_glyph` to do it's wrapping magic.
Something something Occam's something.
Also added `TextCached::new_empty()`, mostly because I can.
Added more notes; convenience conversion for `TextParam`.
This equalizes queueing and drawing with direct drawing.
Cached metrics now don't require mutability everywhere; thread safety and return correctness on `RwLock` poisoning is guaranteed (hopefully I haven't missed anything).
|
This is pretty much done, now. Summary, details, and everything else should be apparent from documentation and example. There are still a few bits to tighten (all marked with I'll check up on my other projects, and start working on fully supplanting current |
This is a work in progress; I feel that having specific diffs in front of us makes it easier to discuss exact implementation of #132 (start of discussion can be found there).
(Side note: trying to adopt verbose commit messages, instead of post-factum dissection in comments.)