Repository navigation
Android PlatformView creates inaccurate path for RoundRect clips #164595
Description
As mentioned in #164258 the code that turns a PlatformView clip is not producing a proper rounded-corner rectangle path. When that PR attempted to use a standard path conversion, it caused golden diffs. The code should be updated to do the proper conversion and the goldens updated separately from that code-migration PR.
Activity
[-]iOS mutator creates inaccurate path for RoundRect clips[/-][+]iOS PlatformView creates inaccurate path for RoundRect clips[/+][-]iOS PlatformView creates inaccurate path for RoundRect clips[/-][+]Android PlatformView creates inaccurate path for RoundRect clips[/+]flar commentedon Mar 7, 2025
After implementing #164753 this may no longer be an issue since that new mechanism uses "the original path" for conversion.
But, we now have a number of issues that interact with each other. The issue at the time of the original PR was that we had Impeller recognizing the shape and rendering the ovals/rrect using direct elliptical tesselation and the path converter code using the "Impeller-converted" path to do a path conversion over the same path. That was fixed with a workaround in that PR by having the android clip path conversion recognize and down-convert the same simple shapes. That fix was later moved up into the clip layer code to avoid sending path mutations down for simpler shapes in #164693
In simplifying the path conversion code in #164753 though we now have a case where the impeller conversion of the path will have inaccurate quads, but the version being iterated in the clippath mutator conversion will pass along the conics. Which path is converted (the original or the impeller variant) will have an impact on whether the paths match, but there is not a lot of information to go on there.
99.9% of this will go away if we implement direct tesselation of conics in Impeller (see #163563) at which point all path rendering code will be using path descriptions that match to a very high precision.
jonahwilliams commentedon Mar 10, 2025
@flar I though the issue was the iOS path conversion from Sk/DlPath to the CGPath?
flar commentedon Mar 10, 2025
...-ish.
It gets more complicated with the new DlPath conversion mechanism. There is a lot of "how will this be rendered and how should we take that into account when communicating the paths to the platform" that is all muddied up and we've gone into, and out of, fidelity with each change.
Really, the answer is to have Impeller implement conics at high fidelity and also to do "de-conic" conversion at a high fidelity and then we stop caring about details like this that will just end up being a game of wack-a-conic until then. (Actually de-conic'ing at a high fidelity would be "enough", but Impeller would do well to just implement direct tessellation of them.)
flar commentedon Mar 10, 2025
If we do better conics in Impeller then this specific case is fixed in practice by the fact that the Android platform accepts the conics and Impeller renders them with high fidelity.
But other platforms don't necessarily accept conics, so to solve it for everyone would require us to have higher fidelity conic to quad/cubic conversion. Also, that better conversion would improve Impeller's rendering "enough" to match much better.