Specifying the `--enable-impeller` flag will switch the renderer to using
Impeller instead of Skia. On platforms where Impeller is not supported, this
flag is ignored.
The notion of the `flutter::SurfaceFrame` has been augmented. Now, in the
absence of a Skia surface to render to, the surface frame will render into a
display list instead.
Impeller variants of the context and surface variants have been added to
`shell/gpu` and `shell/platform`. The variants prepare surface frames that
don’t/can’t specify a Skia surface thus forcing the surface frame to render to a
display list instead. Then, in the submit callback, they forward the display
list ops to the Impeller display list dispatcher.
This scheme has been chosen as it requires the fewest updates to engine
internals which all depend on Skia data structures. Instead of updating all
call-sites to be Skia neutral, the display list interface itself is being made
graphics package agnostic.
* Only creates 'onscreen_surface_' when it's not available in 'AndroidSurfaceGL::CreatePbufferSurface'
* Rename the function and add some unit tests
* Update android_surface_gl.h
Co-authored-by: Dan Field <dfield@gmail.com>
* 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
* Reland "Use a Pbuffer surface when the onscreen surface is not available for snapshotting on Android (#27141)" (#27607)"
This reverts commit 78663924741a29aeca10648015e39db6fbd28be4.
* Do not let gradle download SDK deps
* Revert "Remove GetExternalViewEmbedder from surface (#22272)"
This reverts commit 9dffddd08d0ad6fa7434c5a5bdff87e09da92e57.
* Revert "Rasterizer is initialized with an external view embedder (#22405)"
This reverts commit 417c869d6bcd70ba82fdd6efc8db1efa19fb997c.
Cleans up header order/grouping for consistency: associated header, C/C++ system/standard library headers, library headers, platform-specific #includes.
Adds <cstring> where strlen, memcpy are being used: there are a bunch of places we use them transitively.
Applies linter-required cleanups. Disables linter on one file due to included RapidJson header. See https://github.com/flutter/flutter/issues/65676
This patch does not cover flutter/shell/platform/darwin. There's a separate, slightly more intensive cleanup for those in progress.
This is part of a larger effort to expose the difference between GrDirectContext,
which runs on the GPU thread and can directly perform operations like uploading
textures, and GrRecordingContext, which can only queue up work to be delivered
to the GrDirectContext later.
