-
Notifications
You must be signed in to change notification settings - Fork 29.8k
Description
While flutter/engine#56726 added support for the basic rounded superellipses that have uniform, symmetrical corner radii, SwiftUI supports more styles:
- Uneven rounded rectangles: corresponding to SwiftUI's
UnevenRoundedRectangleclass - Asymmetrical rounded rectangles: corresponding to SwiftUI's
RoundedRectangleclass withcornerSizeparameter
For completeness we might want to support them.
I think both of them are of low priority since I can't think of any use cases. But I'll write down my research progress in case we pick it up some day.
Neither of them seems to use any new technologies. However there are a few obstacles.
Asymmetrical RSE
Asymmetrical RSEs are basically elongated version of a normal RSE.

Radius capping is simply done by capping both dimensions at min(height, width)/2.
| Shape size | Target corner size | Corner size cap |
|---|---|---|
| 100x200 | ___x25 | 50x25 |
| 100x200 | 25x___ | 25x50 |
| 100x300 | 30x___ | 30x50 |
Uneven RSE
Ueven RSEs seem to be simply concatenating 1/8 arcs from a square-like RSE.
However, radius capping seem to follow a more complicated pattern, and I fail to summarize a simple algorithm.
API
Another problem is come up with a beautiful API that unifies both classes, because RSE class can not simply use the Radius class used by RRect, since both asymmetrical RSEs and uneven RSEs have their restrictions, and they jointly don't cover max flexibilities allowed by Radius (not all 8 radii are freedom on their own).
One way to simplify this problem is to ignore asymmetrical RSEs, since they are defined in such a weird way that I doubt will meet any user's expectation, and that they can theoretically be achieved by simply scaling. However, be cautious of precision because the current RoundSuperellipseGeometry tessellates on its own with 1point per px without considering scaling. (Maybe it can dynamically decide the tessellation step based on context transform matrix?)
Without asymmetrical RSEs getting in the way, theoretically we can expand the scope of support to arbitrary Radius. This requires the capping rule to be altered, probably into the same way as the current RRect - which might be actually a good idea. However, supporting arbitrary Radius for RSEs might be mathematically hard, if possible at all.