No functional change. Makes the display list subsystem easier to navigate as the
major classes are in their own TUs. Also avoids importing unnecessary headers
when the previous kitchen sink header was imported. I've tried to remove all
display list related imports and start from scratch but I may have missed some
files. Minor structs and classes (like the ones in utils, ops, etc..) still
don't get their own TUs though.
There were [two](https://github.com/flutter/engine/pull/29562) [related](https://github.com/flutter/engine/pull/30484) changes being made to this subsystem that have since
landed. So I don't think I am stepping on anyones toes with the reorganization.
Happy to incorporate any work-in-progress changes being made to the this
subsystem before submitting.
* Revert "Fix eglPresentationTimeANDROID is no effective (#30182)"
This reverts commit 0d7ba05d3456807e7e24353fe911738952a02888.
* Revert "Use eglPresentationTimeANDROID to avoid bogging down the GPU (#29727)"
This reverts commit edb87942de0404a2802351c050a4f1b6de239bd7.
Fixesflutter/flutter#93352
Improves Android benchmarks on both Pixel 4 and a lower end Android Go device for 99th percentile and average raster times.
This works by telling the system compositor what timestamp we intended to show this frame for. This way, if we end up with a frame that gets submitted right at the beginning of a vsync and then a second frame submitted on the same vsync, the compositor will only try to show the second frame on the screen and save the GPU some work.
Without this, a situation like that results in an "avalanche" of calls where the GPU is behind the CPU and keeps delaying CPU work until we finally stop submitting frames. This can be observed as a lengthy dequeuBuffer in a systrace enabled trace, as shown in the linked issue. This avalanche is often triggered by a frame that does a shader compile through a couple vsyncs and then is followed by a bunch of very fast frames that take less than a vsync to render - the first of those fast frames gets delivered before the end of the vsync that the slow frame ended in.
We cannot implement this ourselves because we don't know how long the swap buffers call will take on the system side, and if we try to guess we can very well get it wrong.
I've filed issues to look into adding this for Vulkan and Metal, although we should also first take traces there to make sure it's warranted.
See also: https://android-developers.googleblog.com/2020/04/high-refresh-rate-rendering-on-android.html
* Take SUPPORT_FRACTIONAL_TRANSLATION into account when diffing layers
* Store cull_rect in device coordinates
This removes the need to update cull rect coordinates when overriding transform
and is also consistent with how Layer::needs_painting() works.
* Use original transform for culling, but overriden transform to get paint coordinates.
This is to replicate the paint process during diffing, where layers are culled first and only then after paint the matrix is overriden.
* Rewrite AddLayerBounds based on @flar's suggestions
