Utilize client composition more efficiently (or partial flattening)
In case some of layer group isn't updating, try to force them to client before any other combination. In case succeed there is a big chance to use the same client buffer in the next frame without having to redraw it by GPU at all. Do it especially when there is client range due to other limitations.
SF should detect client composition reusing and avoid any work in case nothing changed: https://cs.android.com/android/platform/superproject/+/master:frameworks/native/services/surfaceflinger/CompositionEngine/src/Output.cpp;l=891;drc=b4947572c3947dcaf1a96fdc0d91e6478953f975
Example: When we have choice to offload GPU, we can consider to optimize load for current frame only or also for the following frames too:
| Frame # | Single-frame (GPU pixops) | Predictive (GPU pixops) |
|---|---|---|
| Frame n | 1mpx | 4mpx (Full redraw of client page) |
| Frame n+1 | 1mpx | 0mpx (Reuse client page) |
| Frame n+2 | 1mpx | 0mpx (Reuse client page) |
| Frame n+3 | 1mpx | 0mpx (Reuse client page) |
| Frame n+4 | 1mpx | 0mpx (Reuse client page) |
| ... | ... | ... |
| Frame n+x | 1mpx | 0mpx |
The second choice may give the benefits in a total power savings due to client layer caching:
Predictive pixops calculation require to collect some statistic and rely on many inputs. Should be done using TDD approach to ensure we are not making things worse.
Switching from normal to predictive state may introduce additional GPU work to compose first reference frame. This may create single-frame jank.
By doing this we should also reduce power consumed by the display controller and make more shared planes accessible for other displays.