Optimization attempt [WIP]

[desugar-64]

Note

This is a draft version of the PR, which I will continue updating during development. Currently, there are several logs and benchmark traces in the code to visualize performance bottlenecks and identify areas needing optimization. These logs and traces will be removed in the final version.
Please note that the code changes in this PR are not final. These are preliminary modifications aimed at outlining the potential impact of the optimization strategies. The final PR version will include improvements for readability, efficiency, and maintainability.

Related to #43, #44

Summary

I created a basic benchmark to track key performance metrics. Here are the results:

blurScopeAverageMs        18.6
renderImageAverageMs       4.5
fetchBitmapAverageMs       5.9
blurAverageMs              6.2
iterativeBlurAverageMs     8.1
nativeBlurBitmapAverageMs  6.1

Perfetto trace to examine the hierarchy and relative cost of each operation

blurScopeAverageMs represents the total time spent on the entire blurring operation. Currently, this takes about 18ms per frame, which is quite expensive. Given the display's refresh rate of 90Hz on a Pixel 6 I tested on, our frame budget is around 11ms, meaning this blur process is exceeding our budget.

Analysis

We have a few costly operations, including:

1. Rendering to Hardware Bitmaps using GraphicsLayer and then fetching data from GPU memory to CPU, which is expensive and time-intensive.
2. Blurring Process – well optimized with RenderScript Toolkit(ported version) using SIMD and ARM assembly but still costly when run on full-resolution bitmaps.

Potential Optimizations

1. Move Blurring to a Processing Queue

To prevent blocking the onDraw, we could offload the blurring to a processing queue that continuously updates an output state, drawing the resultant bitmap as needed.

2. Output Bitmap Caching

Simple caching of the output bitmap has already shown improvements. By reusing the output bitmap instead of recreating it each time, we reduce redundant allocations. To further refine this, we’ll need to monitor the cached bitmap’s configuration and dimensions to ensure they match the input bitmap.

Benchmark Results with Caching

Initial benchmarking shows improvements with cached output bitmaps:

// Performance comparison
blurScopeAverageMs        18.6 ➔ 18.8  🟡 (+0.2) [Minimal regression]
blurAverageMs              6.2 ➔ 5.6  ✅ (-0.6) [Improvement]
iterativeBlurAverageMs     8.1 ➔ 7.3  ✅ (-0.8) [Improvement]
nativeBlurBitmapAverageMs  6.1 ➔ 5.6  ✅ (-0.5) [Improvement]
...

Additional Improvements Under Consideration

• Input Bitmap Downsampling: Since blurring is a lossy operation, we could reduce the input bitmap size, especially for higher blur radius, to lower the processing overhead without significant visual impact.

This is an ongoing PR; further updates and optimizations will be documented as development progresses. At least I'll try 😅