Resolve BorderRect ambiguity

[ickshonpe]

Objective

In UI and world coordinates, “top” and “bottom” mean opposite things, so these fields are ambiguous. Anyone using BorderRect must decide themselves how to intepret the vertical inset values.

Fixes #21913

For more in detail motivation, see the replies to issue #21913

Solution

Replace the directional BorderRect fields (left, right, top, and bottom) with min_inset and max_inset Vec2 fields.

Using min_inset and max_inset removes the need to interpret top or bottom relative to the coordinate system, so the same logic will work consistently in both UI and 2D.

[kfc35]

Thank you for this!

[kfc35]

nit: for consistency with the other constructors, you can assign these insets to separate Vec2::new’s

[ickshonpe]

Not sure what you mean, this?

    pub const fn axes(horizontal: f32, vertical: f32) -> Self {
        Self {
            min_inset: Vec2::new(horizontal, vertical),
            max_inset: Vec2::new(horizontal, vertical),
        }
    }

I prefer the the single Vec2 constructor version I think as less error prone, though the difference is very marginal.

[ickshonpe]

I also considered swapping axes parameters to a Vec2. I think it might be more ergonomic, but a vector implies direction. The inputs here are directionless, so the semantics with separate f32's feel better to me.

[Hilpogar]

From what I understand, the min_inset is supposed to be the top_left corner in the UI coordinates and the bottom_left corner in the 2D World coordinate. But in the code, you consistently used the top_left corner as the min_inset for both the sprite and the UI. Is it an error or am I missing something ?

[ickshonpe]

From what I understand, the min_inset is supposed to be the top_left corner in the UI coordinates and the bottom_left corner in the 2D World coordinate. But in the code, you consistently used the top_left corner as the min_inset for both the sprite and the UI. Is it an error or am I missing something ?

Yep the compute_slice functions are written in a weird way, but this is correct. Because it was so confusing, I modified the sprite_slice example to use a non-homogeneous border to make sure:

It's not worth cleaning up compute_slice though, instead the 2d sprite slicer needs to be rewritten to use a shader like the UI version does. You can see visual artifacts in the screenshot above due to floating point errors leaving gaps between the slices too, which wouldn't be present with a shader based solution. Plus the performance is abysmal, it's drawing about 50,000 sprites just to display those four bordered rects.

[Hilpogar]

Thank you for the visual checking !