@nicoburns any idea?

Hmm... no that's weird. It looks like it's about the right size in the x axis but it's getting stretched by about a factor of 2 in the y axis :/

That because width is set, but height isn't. If you remove width from style, you'll see big icons with correct proportions.

@mockersf I set height same as width and got

correct result. Is this change good enough solution, or someone should dig deeper and figure out why taffy changed behaviour?

For overflow_debug same thing: height is set, but width isn't. If add width: Val::Px(400.0),, then result

looks correct

But if this solution gets approve, then I think we should add some notes to Migration guide, because such things could be in bevy users code

Or better add some check/warning in bevy_ui::layout::convert::from_style(...) -> taffy::style::Style

Is this change good enough solution, or someone should dig deeper and figure out why taffy changed behaviour?

No, images should keep their ratio when you set only one of their dimension

Yeah, this definitely ought to be fixed in Taffy and/or bevy_ui (wherever the bug is)

@mockersf The problem hides in taffy, because at some point size fills None by measured_size which is done componentwise. So there Size(Some(45), None) becomes Size(Some(45), Some(100)) which has no correct ratio. Looks like there is no issue in taffy for such case.

I think the issue here is with the image measure function. It ought to read the image node's Style and use the size, min_size and max_size as part of it's computation. For most (all?) other "leaf" nodes this is automatically applied by Taffy, but that doesn't work for images because of their inherent aspect ratio.

I agree with your desire for universal approach, but IMO size is already width and height which we fill partially, and min_size and max_size is for clamping but not for ratio description, if there is width or height set only, image should be abble grow or reduce unlimitedly but proportionally. I read the contribution.md page of taffy, it says that behaviour must be similar as in chrome css render. That's why IMO we should make html example first (test?) for taffy and reproduce this issue. If chrome behaves as we expect, but taffy doesn't, then this is the basis for creating a well-formed issue in taffy project. Otherwise it should be local fix in bevy_ui, perhaps UiImage could autofill the width or height or better aspect_ratio in Style at some stage.

I didn't notice that bevy doesn't inform taffy about node types, that's why taffy can't make correct decision about size behaviour. I think Style::aspect_ratio is correct approach, I will make PR based on it.

@alice-i-cecile Just wanted to call attention to this issue. It's a really not great regression which I believe it caused by the interaction between Taffy and Bevy's measure function. I don't think the fix should be too hard (either need to expose taffy's Style to the measure function or inherent aspect ratios to Taffy - the former is probably an easier quick fix), but it's a bit of an awkward one because I think it will require breaking changes in Taffy and then another Taffy upgrade in Bevy.

(but luckily Taffy doesn't have any other unreleased changes sitting around, so the upgrade should be quite straightforward).

What kind of release date is 0.14 targeting?

We're looking at 1-2 weeks for the release candidate. I agree that this is important to resolve.