* Implemented wide gamut images for iOS
Moved the surface to an extended range color format.
* wrong gamma but default pixel format set to bgra10_xr
* BGR10_XR add
* format
* updated todos
* updated todo with information about pixel formats
* switched logic for determining if we have a wide gamut image
* cleaned up gamut math to match style and linked source
* made the color attachment pixel format match the surface
* updated vulkan format switch
* removed comment
* added enable disable switch
* moved default to bgr10 for now since there is a bug where someone is still reading this, msaa?
* fixed the decoder settings to make sure we don't lose wide gamut colors
* fixed stored srgb gamut variable
* fixed false lint
* updated test
* added ability to grab the surface data for tests
* made the screenshot utility return the format
* added width and height to the platform channel payload
* fixed a couple of broken targets
* moved back the default pixel buffer format
* cleanup and add docstrings
* made the surfacedata feature only available in debug builds
* added decoding unit test
* fixed objc tests
* turned off by default
* bdero feedback1
* bdero2
* bdero3
* fixed merge issue
* removed using std::shared_ptr
This ensures FlutterMetalTexture.destruction_callback gets called.
FlutterRendererConfig.get_next_drawable_callback holds a callback used by the embedder API to request a drawable; in the case of Metal, this drawable is a FlutterMetalTexture.
FlutterMetalTexture.destruction_callback should be called when it's safe to release resources associated with the FlutterMetalTexture. This callback is not currently invoked for textures returned via FlutterRendererConfig.get_next_drawable_callback; instead we unpack the returned struct and pass it on.
In the compositor codepath, we do create an SkSurface that triggers the destruction callback, here:
bbdb5d6a3e/shell/platform/embedder/embedder.cc (L868-L881)
Issue: https://github.com/flutter/flutter/issues/116381
If the following is added to Info.plist of the application,
it will disable partial repaint:
```
<key>FLTDisablePartialRepaint</key>
<true/>
```
The primary intended usecase for this is to enable applications to see if disabling partial repaint resolves:
https://github.com/flutter/flutter/issues/100522.
Roll Swiftshader, ANGLE, and Vulkan deps.
Updates license bot for new locations of licenses and new files
in roll.
Converts unit test harnesses to use SwANGLE, which is the
supported way of using SwiftShader as a software backend for GLES.
Updates goldens due to swiftshader changes.
Fixes up include paths to avoid directly including third_party
code by that name, which is unlikely to work in other build
environments.
Includes upstream patches to ANGLE and SwiftShader to build in our
windows environments, as well as patches to Skia to support
defining the location of VulkanMemoryAllocator and a patch to ANGLE
to support opting into a newer version of VMA.
Merges most (but not all) of the impeller .clang-tidy rules into the
main .clang-tidy config. Merges:
readability-identifier-naming.PrivateMemberSuffix (_)
readability-identifier-naming.EnumConstantPrefix (k)
modernize-use-default-member-init.UseAssignment
Does not merge:
readability-identifier-naming.PublicMethodCase (CamelCase)
readability-identifier-naming.PrivateMethodCase (CamelCase)
These last two are not merged due to the non-trivial number of existing
field accessors that use field_name() methods to directly return
field_name_. While these are permitted by the C++ style guide, we may
want to move to a single, simple rule and name everything in CamelCase.
These can be enabled in a followup patch.
No new tests added, since this change is style-only.
Towards implementing the FragmentProgram API in Impeller.
Specifies an Impeller specific format for data the renderer can use to create
pipelines with user supplied shader stages at runtime.
The data is in the form of a flatbuffer with a known schema.
This patch implements the wire format, creating and loading the program
payloads, and creating pipeline state objects using these payloads.
If the user supplied SPIRV intended for the older API, the loader will reject
this invalid payload. This is probably not going to be too much of an issue
because the FragmentProgram API will probably be modified to only allow buffers
loaded from asset managers. But still, in the meantime, I am using the old API
to pass these new buffers.
Fixes https://github.com/flutter/flutter/issues/104750
Fixes https://github.com/flutter/flutter/issues/105542
Towards resolving https://github.com/flutter/flutter/issues/102853
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.
* 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
Context creation options for each backend were spread across multiple
translation units. This makes setting options common across all backends hard to
configure. I have moved the creation of such common options into a separate
translation unit.
Fixes https://github.com/flutter/flutter/issues/84213
This option will be the default in Skia soon. Per discussion in #26067, let’s be explicit about disabling it for the time being, and we can revisit the flag in the future if desirable.
Used the the `misspell` tool available at
https://github.com/client9/misspell, then applied hand-corrections. It's
possible we could adopt this as a presubmit, but there are still enough
false positives that it may not be worth the effort.
