-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Ui Node Borders #7795
Ui Node Borders #7795
Conversation
* Added the module `border` * Added `BorderStyle` and `CalculatedBorder` types. * Added `border_style` and `calculated_border` fields to `NodeBundle` and `ButtonBundle` * Added the `extract_uinode_borders` system to the UI Render App. * Added the `calculate_borders_system` which calculates the border geometry for each node. * Added the UI example `borders` * Changed the button example to give the button a border.
I'm not sure what the overflow behaviour for borders should be. I have it clamp the border thickness to the size of the node at the moment, which seems reasonable enough. |
As far as I can see, Chrome will always expand nodes to fit borders. And it seems that Taffy also implements this. So from Bevy's perspective, I think this will be a case of "never happens" (or at least shouldn't). |
Update: Taffy does not in fact do this. We'll probably want to fix Taffy here. |
Would it be possible to combine this PR with creating a new type specific for borders instead of |
…ers in `calculate_borders_system`
I think I'd prefer to keep this PR just focused on the implementation if we can. |
If this refers to what happens when border overflows I suppose it depends on the parent node "overflow" property? Related though, is how the border affects the node size (CSS I mean, if the node has 200px width, and has a 10px border, which is the size of the node? 200px? 220px? (ignore me if this unrelated 😅 ) |
It is indeed 200px (the border grows inwards) because we use |
I'm old enough to have suffered those CSS quirks… 😅 Anyway, I was asking because ickshonpe was asking about overflow behaviour; for a moment I though Bevy wasn't doing Although, I totally forgot that the sum of borders could be bigger than width… nice that it's being fixed. The PR you link means that size will be computed as: Btw, unrelated, but just wanted to mention that you're doing an amazing job with Taffy. ❤️ |
We're definitely doing
Yes, although the computation of
Thanks! |
running example
I think it's probably OK but there's definitely a perf impact |
Yep considering that by adding borders to many_buttons you draw an extra 50000 quads it's not that bad. If performance is really crucial you can always fall back to the old method of drawing a border by using margins or padding to draw a node within another node. |
…ed from parent width.
match value { | ||
Val::Auto => 0., | ||
Val::Px(px) => px.max(0.), | ||
Val::Percent(percent) => (parent_width * percent / 100.).max(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.
I'd like to see a comment here about why we decided to use parent width specifically. IIRC it's consistent with CSS, but it's arbitrary enough that it's helpful to call out.
}, | ||
]; | ||
|
||
let transform = global_transform.compute_matrix(); |
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.
This name is quite unclear.
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.
This is just the regular transform of the uinode. In the loop it's translated to the center of each rectangle that constitutes the border. It feels to me like it might be confusing to call it anything else.
Approach seems good, code is generally good. Examples are fine, if still pretty artificial. There are a few tricky bits of math that would really benefit from a bit more explanation. |
@natasria could we get your opinion on this PR vs 8381? They're both trying to do the same thing: we should pick one and merge it for the upcoming release :) |
Well, feature-wise #8381 has border radiuses, but it forces the borders to be the same for all sides, this PR allows specifying for different borders in the sides. #8381 still have rough edges to polish on border radiuses (it's just aliased borders so the name is true? <3 ) and sharp transition issues too, but I don't feel it's a blocker. |
I've just realized the border limitations, oh my god. T_T |
Objective
Implement borders for UI nodes.
Relevant discussion: #7785
Related: #5924, #3991
Solution
Add an extraction function to draw the borders.
Can only do one colour rectangular borders due to the limitations of the Bevy UI renderer.
Maybe it can be combined with #3991 eventually to add curved border support.
Changelog
BorderColor
.extract_uinode_borders
system to the UI Render App.borders