You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
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.
Was doing some digging on
canvas.withSaveLayer
and noticed that its documentation says: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
The text was updated successfully, but these errors were encountered: