@jonahwilliams Can you take a look and see if this approach is acceptable?

I'm not really convinced that subpixel accuracy is necessary for accurate hit testing (which already has a slop of 8-16 px) compared to the rrect approximation.

I agree, so I might not apply this to the clipping. However the ability to convert RSE to paths is crucial (such as to create a corresponding class of RoundedRectangleBorder) and we need this FFI to achieve this. This PR is mostly a baby step before the path changes.

If you're converting the RSE paths then you're essentially falling back to the RRect or bezier approximation, which seems to defeat the purpose of a high fidelity backend implementation. If that is an acceptable trade off, then you should instead perform the bezier approximation in the framework and remove the engine specific API.

Can we instead adjust the API in the framework where needed to support more than Paths?

The path is used in ShapeBorder.innerPath and outerPath. The two methods are supposed to be used as fallbacks. I agree that the fallback should be defined by backends, instead being forced upon all shapes.

I'll investigate whether I can deprecate these methods. Meanwhile I'm closing this PR for now.

This pull request has been changed to a draft. The currently pending flutter-gold status will not be able to resolve until a new commit is pushed or the change is marked ready for review again.

For more guidance, visit Writing a golden file test for package:flutter.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

@jonahwilliams I've searched get(Inner|Outer)Path throughout the repository and the paths are used in a lot of widgets to paint and clip. Although I still agree that these two methods should be refactored away and think it's theoretically possible (I'm also asking the original authors to see if there are any reasons for the current design.), it would be a really big project. For example, some of the acquired paths are stored and used later, which is going to take non-trivial efforts to refactor away.

Therefore I think we should move ahead with the path implementation and seek to perform the refactor in a separate project.

Lets talk about this one tomorrow too. I have more questions, it will probably be faster to chat in person.

KK so I did some profiling of figma_squircle and ... I can't say its any slower? If anything it can be a bit faster on older hardware, possibly because the RSE tessellator is generating more geometry (though I'd need to investigate it).

So If there are no performance issues, its fine to use the bezier appromination - and the RSE geom can just be a specialization of that.

So no changes needed for this PR @dkwingsmt , beyond review feedback

Thank you! I'll take a look at the comments.

I've significantly changed and simplified the design.

• The native class of Dart RSuperellipse is no longer a subclass RSuperellipse, but is instead a regular native class with no storage, called _NativeRSuperellipse.
• The Dart RSuperellipse class no longer caches _NativeRSuperellipse, and the C++ RSuperellipse class no longer caches RoundSuperellipseParam. Caching can always be added later (we can store the param as a private field), but such optimization should be added based on benchmark.
• There are no more getValue. Dart RSuperellipse's values are store twice, both in Dart and in C++.