Conversation
|
I really like this change. It's more granular, allowing us to be lazier about recomputations, but IMO it's also much clearer to users. |
|
It looks like the current status of the examples is that they've been find/replaced, but many are likely broken in an obvious way. Feel free to ping me when this is ready for review. |
|
This all sounds good to me. Adapting my framework to work with this will not be difficult. |
alice-i-cecile
left a comment
There was a problem hiding this comment.
I spotted a couple of missed internal renames, but those are just nits :) Nice stuff!
pablo-lua
left a comment
There was a problem hiding this comment.
Big changes. I have some questions
|
|
||
| impl AnimatableProperty for FontSizeProperty { | ||
| type Component = TextStyle; | ||
| type Component = TextFont; |
There was a problem hiding this comment.
If I understand the bevy error 0005 correctly, we shouldn't generally be changing the size of a font this way, and instead use transform or ui_scale. Should this example continue to teach this possible footgun to the users?
There was a problem hiding this comment.
Yeah I agree it's not a good example, it should probably be removed. Scaling the foot using transform isn't normally a good solution either as the text will end up blurred (or blocky if you turn off anti-aliasing). It's outside the scope of this PR to fix it though I think.
| Text::new("Bevy Game Menu UI"), | ||
| TextStyle { | ||
| TextFont { | ||
| font_size: 67.0, |
There was a problem hiding this comment.
Question: generally we only set the size of the font when creating it. Is it possible that we maybe add a shorthand method for this? like TextFont::from_size(size: f32)
There was a problem hiding this comment.
Yeah I agree it's annoying. FontSmoothing is quite niche as well, I'd rather it was a separate component.
I want to keep this PR to just dealing with color though as it's the biggest problem.
There was a problem hiding this comment.
I have some slight reservations about ux, particularly the amount of
let text_style = (
TextFont {
// ...
},
TextColor(/* ... */)
);now happening, which I think will be very common in user code.
But if we're happy with the design then the code looks good to me. The benefits are certainly obvious.
pablo-lua
left a comment
There was a problem hiding this comment.
I'm fine with the changes and has some good improvements. I have one small nit, but otherwise LGTM
Yeah I think what this needs is just text font + color inheritance flowing down the tree, It's trivial to implement a basic version, but maybe depends what's being planned with bsn etc. |
| writer.for_each_style(entity, |mut style| { | ||
| *style = overlay_config.text_config.clone(); | ||
| writer.for_each_font(entity, |mut font| { | ||
| *font = overlay_config.text_config.clone(); | ||
| }); | ||
| writer.for_each_color(entity, |mut color| color.0 = overlay_config.text_color); |
There was a problem hiding this comment.
Can we keep for_each_style and have it pass both the font and color as params?
There was a problem hiding this comment.
We could but I'm wondering if all these helper functions are even needed though. Users can just use for_each and ignore the fields that they don't need? We could return a struct with named fields instread of an optional tuple to make it more ergonomic.
There was a problem hiding this comment.
Yeah, I believe that we should leave this helpers to a follow-up PR so we can discuss better what to do with them
Objective
Currently text is recomputed unnecessarily on any changes to its color, which is extremely expensive.
Fixes #14875
Solution
Split up
TextStyleinto two separate componentsTextFontandTextColor.Testing
I added this system to
many_buttons:reports ~4fps on main, ~50fps with this PR.
Migration Guide
TextStylehas been renamed toTextFontand itscolorfield has been moved to a separate component namedTextColorwhich newtypesColor.