-
-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Text refactor #470
Text refactor #470
Conversation
I'm a bit frazzled at the moment so I'll get round to a review later (sorry), but as for
How about |
I've also implemented an example of an external text renderer in my fork of the It can be used to draw seven segment displays with any scale: The code is too complex to keep it as an example, but I think it could be useful to release the renderer as a separate crate. |
Never mind, it's only a draft PR and you can review it when it's done.
Sounds good to me, thanks for the suggestion. |
break Some(Pixel(Point::new(x, y), color)); | ||
} | ||
} else if let Some(current_char) = self.current_char { | ||
let color = if F::character_pixel( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While it's not a huge difference, this lookup has a bit of perf impact. In embedded-text, I made a glyph renderer struct that contains the pixel offset instead of the character and avoids some unnecessary re-calculations for each pixel. Also I think it would be nice if this code could be reused in embedded-text, but I think I might implement that after this is merged :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to try to reuse the RawDataIter
that is used to draw images. This would reduce some code duplication but I'm not sure about the performance impact yet. If that doesn't work out we can look into optimizing this code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While it's not a huge difference, this lookup has a bit of perf impact.
Did you see a perf impact running just bench font
? I realise they're contrived benchmarks and perhaps not representative of realworld performance, but the text benches improve ~10% for me on this branch compared to master
.
1a40674
to
784d7f7
Compare
break Some(Pixel(Point::new(x, y), color)); | ||
} | ||
} else if let Some(current_char) = self.current_char { | ||
let color = if F::character_pixel( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While it's not a huge difference, this lookup has a bit of perf impact.
Did you see a perf impact running just bench font
? I realise they're contrived benchmarks and perhaps not representative of realworld performance, but the text benches improve ~10% for me on this branch compared to master
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My eyes have gone a bit square looking at the word Mono
over and over again, but looks good overall.
One thing that's missing that I think is important is an example of implementing a custom font. I don't know if it's possible to add one that's short enough to show in the docs, but it would really help tie all the traits and structs together.
There's a reference to the text-custom-font
simulator example somewhere (I can't find it in the diff now for some reason) which might be worth turning into a link too.
I couldn't reply to this above:
I hadn't noticed that before, but I also get some performance improvements. Not quite 10%, but I hadn't expected any performance gains at all, so the 3%-7% are also welcome. Since the benches were updated to use a framebuffer they should be pretty representative, but only for displays drivers with a framebuffer. Perhaps we should look into also adding benches for other displays, where the number of draw calls or the amount of data that has to be transmitted are better metrics. |
Co-authored-by: James Waples <[email protected]>
9d20762
to
6ee2f79
Compare
An example in the docs wouldn't be much shorter than |
I thought that might be the case. No worries - we can add more in later. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good from my side. I don't know if @bugadani had anything else to add?
Don't wait for me, I can't review in depth :( |
@jamwaffles If I decide to convert this example into a reusable crate do you think it would be useful enough to be an official e-g project or should I release it myself? |
I think it'd be right at home in the e-g org if that's what you mean. Would it end up being published on crates.io? As complex as it is, it would also be a good example for those looking to implement a custom font. |
Yes, that's what I meant.
Yes. IMO a freely scalable seven segment font could be useful for different projects.
Just to be clear: It's not a custom font, but a custom text renderer. But I agree that it could still be a good example for how an external renderer can be integrated. |
Definitely! You should be able to make repositories in the e-g org, so feel free to do so when you have time. Let me know if you run into permissions errors.
Right, renderer not font. I'll do my best to be clearer with the terminology from now on :) |
I just wanted to make sure we talk about the same thing ;). |
Thank you for helping out with embedded-graphics development! Please:
CHANGELOG.md
entry in the Unreleased section under the appropriate heading (Added, Fixed, etc) if your changes affect the public APIrustfmt
on the projectjust build
(Linux/macOS only) and make sure it passes. If you use Windows, check that CI passes once you've opened the PR.PR description
This PR adds support for external text renderers to e-g.
TextStyle
was converted to a trait that can be also implemented in other crates. To make drawing more efficient text renderers get direct access to the draw target and can use optimizations likefill_contiguous
. Renderers can implementTextStylePixels
to also provide a pixel iterator, but this isn't required.Are the names
MonospacedTextStyle
andMonospacedTextStyleBuilder
too long? Do you have a better suggestion?