[vector_graphics] Add auto RenderingStrategy for better performance

[gaodi-sec]

Background

Currently, vector_graphics requires manually selecting either raster or picture rendering mode. However, raster mode has limited flexibility, as the generated cache size may not always be appropriate for the current drawing conditions, leading to inefficient rendering. On the other hand, picture mode can introduce additional RenderPass execution overhead.

Changes

This PR adds an auto mode to vector_graphics, which:

1. Determines the actual rendering resolution using the canvas transformation matrix, ensuring a pixel-perfect raster cache without aliasing.

2. Includes color and colorFilter effects in the raster cache. Caches are stored globally, preventing redundant creation when identical icons are used.

3. Switches to picture mode if the calculated rendering resolution exceeds 2048x2048, avoiding excessive memory usage and maintaining performance.

4. Delays raster cache creation by two frames, using picture mode for drawing in the meantime. If properties change before the cache is created, the delay is extended by another frame. This prevents excessive cache regeneration during scaling animations.

5. Staggers cache creation across frames when multiple caches need to be generated, ensuring that only one cache is created per frame. For example, if three icons require caching, they will be generated after 2, 3, and 4 frames, respectively. This minimizes frame-time spikes and prevents UI stuttering.

Issue Fixed

This change addresses #166184, allowing flutter_svg to dynamically adjust its rendering strategy for better performance and reduced manual configuration.

Why doesn't Skia have this performance issue?

Because in Skia mode, there is component-level raster caching that automatically stores the result. However, according to #131206, flutter previously decided not to port the raster cache to Impeller.

Test

When a page contains 20 SVGs, its rendering trace for a single frame is as follows:

Each small SVG requires a short period of time to render(two RenderPass):

Use this auto Strategy, the rendering trace can be this:

Each frame saves a significant amount of time spent on executing RenderPass.

Because we have a limit of generating one raster cache per frame, the frame time gradually decreases as the page with 20 SVGs loads, as shown below:

The raster cache will be generated with a delay of two frames after the component is drawn. It is created in the raster thread, running concurrently with UI operations before the actual rendering occurs:

Once this PR is merged, the changes to integrate this feature into flutter_svg will be proposed.

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/packages repo does use dart format.)
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or I have commented below to indicate which version change exemption this PR falls under¹.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or I have commented below to indicate which CHANGELOG exemption this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩² ↩³