Impeller will stroke paths directly from the original path via iteration #167422
Conversation
github-actions
bot
added
platform-android
|
In the current form, the new code This PR is being submitted in its current form to see how it might impact the golden tests. |
|
GiantStrokeAllocation test is making assumptions about internal vertex production that fail on the new code (mainly because it generates a lot fewer segments). I'll need to see if its assumption is even still valid and to adjust the values it is expecting as necessary. |
|
It looks like the added time for the new code is entirely due to the DlPath impeller path iterator being slow. If I force the path to an SkPath in the benchmarks then the new code is faster than the old code. Notes:
Note that the last 2 variants (StrokeConvertedPath and StrokePath) are representative of the work that DrawPath has to do for the 2 cases of DrawPath if it encounters a DlPath for the first time, or for a subsequent time if the path is reused. The StrokePathSkia case which happens regardless of whether the DlPath has ever been seen before represents the full workflow as well and is faster than even the case where we are stroking an already converted Polyline. The StrokePathImpeller case is identical to the StrokePathSkia case except that we are internally using the impeller path iterator vs the Skia SkPath iterator and it is a mystery how it can be that much slower. Note also that the StrokePathSkia and StrokePathImpeller cases represent a workflow that never has to convert the path from one format to the other (though as we see, iterating the impeller case might want to consider converting to a Skia path for faster iteration if we ever care about that case - we don't care because it is only ever used in unit tests and benchmarks, though). We might want to revisit the impeller iterator performance in a future PR, but since that case isn't used in production code (where ui.Path internally uses an SkPath), that work is of very low priority. |
|
Golden file changes have been found for this pull request. Click here to view and triage (e.g. because this is an intentional change). If you are still iterating on this change and are not ready to resolve the images on the Flutter Gold dashboard, consider marking this PR as a draft pull request above. You will still be able to view image results on the dashboard, commenting will be silenced, and the check will not try to resolve itself until marked ready for review. For more guidance, visit Writing a golden file test for Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
|
Some results from the |
|
Golden file changes are available for triage from new commit, Click here to view. For more guidance, visit Writing a golden file test for Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
|
The |
flar
changed the title
|
Golden file changes are available for triage from new commit, Click here to view. For more guidance, visit Writing a golden file test for Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
|
Looking through the last batch of golden diffs they all look pretty much within the realm of "slightly different math". There was one notable win for the new code: CanRenderQuadraticStrokeWithInstantTurn - on the upper left rounded corner |
…ion (flutter#167422) Currently stroking paths in Impeller goes through a few steps: - [Once per path object, if reused] If necessary, convert a source Skia path to an Impeller path - Ask the Impeller path object to create a polyline, with only line segments each potentially marked as "coming from a curve" - Widen the polyline treating curves specially - render the widened vertex list This PR attempts to streamline that process by iterating the original curve and widening the strokes from that. It will require no conversion of the path from SkPath to impeller::Path (if it was created as an SkPath as is done for all ui.Path objects). It also avoids the intermediate polyline stage. It will also produce fewer outline vertices since it attempts to recognize which vertices are produced by the prior and future line segments and avoid duplicating them.
3 participants
Currently stroking paths in Impeller goes through a few steps:
This PR attempts to streamline that process by iterating the original curve and widening the strokes from that. It will require no conversion of the path from SkPath to impeller::Path (if it was created as an SkPath as is done for all ui.Path objects). It also avoids the intermediate polyline stage. It will also produce fewer outline vertices since it attempts to recognize which vertices are produced by the prior and future line segments and avoid duplicating them.