-
-
Notifications
You must be signed in to change notification settings - Fork 3.9k
split up TextStyle
#15857
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
split up TextStyle
#15857
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. |
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 spotted a couple of missed internal renames, but those are just nits :) Nice stuff!
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.
Big changes. I have some questions
@@ -40,7 +40,7 @@ fn main() { | |||
} | |||
|
|||
impl AnimatableProperty for FontSizeProperty { | |||
type Component = TextStyle; | |||
type Component = TextFont; |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@@ -433,11 +432,11 @@ mod menu { | |||
// Display the game name | |||
parent.spawn(( | |||
Text::new("Bevy Game Menu UI"), | |||
TextStyle { | |||
TextFont { | |||
font_size: 67.0, |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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'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. |
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.
Looking good, just one API request.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we keep for_each_style
and have it pass both the font and color as params?
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
TextStyle
into two separate componentsTextFont
andTextColor
.Testing
I added this system to
many_buttons
:reports ~4fps on main, ~50fps with this PR.
Migration Guide
TextStyle
has been renamed toTextFont
and itscolor
field has been moved to a separate component namedTextColor
which newtypesColor
.