Canvas.saveLayer is relatively expensive

[kelvinwatson]

Was doing some digging on canvas.withSaveLayer and noticed that its documentation says:

Performance considerations

Generally speaking, Canvas.saveLayer is relatively expensive.

There are a several different hardware architectures for GPUs (graphics processing units, the hardware that handles graphics), but most of them involve batching commands and reordering them for performance. When layers are used, they cause the rendering pipeline to have to switch render target (from one layer to another). Render target switches can flush the GPU's command buffer, which typically means that optimizations that one could get with larger batching are lost. Render target switches also generate a lot of memory churn because the GPU needs to copy out the current frame buffer contents from the part of memory that's optimized for writing, and then needs to copy it back in once the previous render target (layer) is restored.

However, the documentation doesn't offer any alternative. Is there any recommendation for replacing this call? https://developer.android.com/topic/performance/vitals/render#rendering_performance_renderthread

[valentinilk]

That's something that is still on my todo list. In the beginning, the method's documentation didn't include the warning. When they added it, I wasn't able to find a better solution. The implementation currently relies on BlendMode, which seems to require withSaveLayer. Open for suggestions. :)

Are you experiencing any lags, due to the shimmer libary?

[valentinilk]

Had a deeper look in the meantime. It is not possible to get rid of the withSaveLayer. As the shimmer is usually not shown for an eternity, the effect on the battery should be minimal.