Make it possible to read bevy-calculated ContentSize.

[nicopap]

Objective

• blocked on Cleanup some bevy_text pipeline.rs #9111

Make it possible to read bevy-calculated ContentSize.

It can be useful to access the pre-layout content size. For example when integrating a different layout engine into bevy. It was previously possible, but #7779 made it impossible, it now requires ad-hoc redundant evaluation.

Although, maybe it's useful for other things as well? See bevyengine/bevy-website#701

Solution

• Replace the private trait object measure_func in ContentSize by enum variants.
• Centralize all bevy ui measurement code in ContentSize::measure method.
• replace set usage with directly setting the enum

The tradeoff is that users can't implement themselves Measure anymore. Which might be a problem. An option is to provide a 4th variant with a trait object. It would make sense, since ContentSize ends up turned into a trait object on use in ui_layout_system in any case.

---

Migration Guide

• bevy_ui's ContentSize::set and Measure doesn't exist anymore. Instead, set its value directly.

[ickshonpe]

My thoughts:

• The need to support other layout engines didn't occur to me at all when I implemented ContentSize 😓

• In my first draft implementation, the measure funcs were publicly callable from the ContentSize components and I used some unsafe hacks to allow Taffy to access the components directly with a query. But I'm not an expert on unsafe rust, so I went with the move solution instead that I knew would work. If an approach using unsafe code is viable that might be better.

  Hopefully, Taffy will have better support for custom LayoutTree impls soon that will allow the layout algorithm to access our measure funcs without hacks or taking ownership.

• I went with trait objects as the main focus of my PRs was fixing the existing bugs and I just wanted something simple and reliable that could be easily replaced later on by a better solution.

  The enum approach seems alright. Another option would be to have separate components like TextMeasure, ImageMeasure, etc instead of enum variants. I'm not sure what the tradeoffs are, but my guess is that an enum is probably the better option.

• I think users definitely need to be able to implement Measure, a fourth variant wrapping a trait object seems like it would be fine. Custom measure funcs are also very useful for debugging.

• ContentSize needs a better name. CalculatedSize was worse, but ContentSize still doesn't capture the right semantics. The name implies the component contains the size, not a function used to derive it. ContentShaper? ContentMeasure? Intrinsic-something?

[nicopap]

So I also needed to expose a way to manipulate ContentSize in cuicui_layout. My solution involves using a SystemParam trait. I've used this style of API several times now (also in ui-navigation) but it's not established in bevy itself.

It's very onerous right now, it's probably possible to simplify it, but I spent a considerable amount of time trying to satisfy the rust type system already.

https://github.com/nicopap/cuicui_layout/blob/a90a40e9be934a8b01ca3271441b07acecb67a01/layout/src/content_sized.rs#L21-L35

[ickshonpe]

Just been thinking about this again after working on #9341. Maybe there are advantages to Measure implementing Clone, and the layout system cloning a Measure instead of moving it. It's less efficient but probably not a big deal as measure funcs don't tend to get updated that often. The implementation of #9341 is way more complicated than it needs to be and cuicui_layout looks to be jumping through way too many hoops too.