Performance: Flutter codec loading, cache lifecycle, and Surface teardown bottlenecks

[q760440238]

Problem

PowerImage's default HTTP path and native Surface lifecycle had several independent sources of latency and cross-request blocking:

• encoded-byte cache misses were not single-flight;
• network/decoding work was not visibility-prioritized at the real first Codec.getNextFrame();
• cache writes, forced flushes, and fine-grained LRU touches competed with first paint;
• ordinary PNG/GIF/WebP could enter native/custom rendering paths instead of Flutter's codec/widget fast path;
• native rendering fenced every frame instead of only teardown;
• Surface release coordination could block unrelated engine/Surface generations;
• native resources depended on global binding/cache hooks instead of the completer's last listener.

Reproducible physical-device comparison

Huawei VOG-AL10, Android 10 / API 29, Flutter 3.38.7, full AOT compilation, identical 512x512 loopback HTTP fixture, 160x160 target, 10 cold iterations. ExtendedImage is pinned to 10.1.0 and CachedNetworkImage to 3.4.1. P95 is nearest-rank.

Cold first displayed frame	P50	P95	peak RSS median
PowerImage	41.967 ms	46.382 ms	251,406 KB
ExtendedImage 10.1.0	42.390 ms	63.427 ms	258,870 KB
CachedNetworkImage 3.4.1	75.667 ms	78.328 ms	259,114 KB

PowerImage is 1.0% faster than ExtendedImage at P50 and 26.9% faster at P95; versus CachedNetworkImage it is 44.5% / 40.8% faster.

Isolated A/B results for the proposed changes

Change	Before P50/P95	After P50/P95	Delta
disk ImmutableBuffer.fromFilePath	32.834 / 38.803 ms	27.509 / 36.203 ms	-16.2% / -6.7%
deferred/bounded cache maintenance	241.172 / 249.526 ms	229.213 / 232.482 ms	-5.0% / -6.8%
schedule the real first getNextFrame()	45.145 / 77.059 ms	41.967 / 46.382 ms	-7.0% / -39.8%
standard Flutter Image widget fast path	44.361 / 60.090 ms	42.646 / 59.193 ms	-3.9% / -1.5%
animated raster queueBuffer average	0.560 / 0.582 ms	0.543 / 0.559 ms	-3.0% / -3.8%

The final animated run submitted a median 826 frames versus 819 before the widget fast path, so the timing change is not caused by dropped frames. Private RSS stayed flat (126,916 KB before, 126,804 KB after).

Four final cache/lifecycle scenarios

Scenario	iterations	P50	P95
cold first frame	10	41.967 ms	46.382 ms
encoded-byte disk hit	20	27.936 ms	48.598 ms
Flutter ImageCache hit	10	15.878 ms	22.868 ms
release/rebuild 100 native Surfaces	5	962.568 ms	2,337.305 ms

All iterations reached their required real-frame completion marker. The final disk-hit distribution contains three 45-49 ms scheduling outliers; the isolated fromFilePath A/B above is the evidence for that particular change.

Raw AndroidX Macrobenchmark JSON, fixture methodology, exact versions, and memory figures are checked in here:
https://github.com/q760440238/power_image/tree/feature/android-animated-webp/example/android/macrobenchmark/results/2026-08-03-VOG-AL10

A corresponding implementation and reproducible benchmark suite is available in PR #59.

[q760440238]

Additional physical-device validation: 20 different animated WebPs visible at once

This extends the cold/cache results above with a steady-state animation test. For reference, the measured cold first-frame comparison remains:

Implementation	P50	P95	peak RSS median
PowerImage	41.967 ms	46.382 ms	251,406 KB
ExtendedImage 10.1.0	42.390 ms	63.427 ms	258,870 KB
CachedNetworkImage 3.4.1	75.667 ms	78.328 ms	259,114 KB

For animated playback, Huawei VOG-AL10 (Android 10/API 29) displayed 20 distinct animations sourced from https://giphy.com/explore/webp in a fixed 4x5 grid (~270x270 physical px each). GIF sources were converted with FFmpeg 8.1.2 libwebp_anim without resize or frame sampling. Each implementation ran 5 interleaved rounds: 12 s warm-up + 20 s sampling, yielding 100 one-second CPU/RSS/GPU-frequency samples and 5 PSS/Graphics snapshots per implementation. CPU 100% means one fully occupied core.

Implementation	CPU P50/P95	PSS P50/P95 KiB	Graphics P50/P95 KiB	Surface FPS P50
PowerImage (Flutter codec)	133.704% / 136.405%	150,736 / 157,014	47,436 / 48,742	60.116
ExtendedImage 10.1.0	133.857% / 136.022%	148,206 / 160,580	48,548 / 53,586	60.132
Pure Android Glide 4.16.0	138.088% / 154.886%	112,489 / 114,503	43,728 / 45,159	60.176

PowerImage and ExtendedImage are effectively tied on median CPU. PowerImage has +1.71% median PSS, but lower P95 PSS (-2.22%), P95 RSS (-3.36%), and P95 Graphics (-9.04%), so its measurable advantage here is memory-tail stability rather than median CPU. Versus pure native Glide, PowerImage uses 3.17% less median CPU and 11.93% less P95 CPU, but pays about 38 MiB additional PSS for the Flutter Engine/Impeller.

All 300 GPU-frequency samples stayed at 139 MHz (device maximum 720 MHz), so the GPU never needed to ramp. The production kernel denies GPU-utilization/perf-counter access; frequency is reported only as a workload proxy, not as utilization.

Raw JSON, full report, source URLs, and material SHA-256:
https://github.com/q760440238/power_image/tree/feature/android-animated-webp/example/android/macrobenchmark/results/2026-08-04-VOG-AL10