This removes most of the remaining FLUTTER_NOLINT comments and opts
these files back into linter enforcement.
I've filed https://github.com/flutter/flutter/issues/68273 to require
that all FLUTTER_NOLINT comments be followed by a GitHub issue URL
describing the problem to be fixed.
Skia is removing the deprecated legacy display setting globals and
associated kLegacyFontHost_InitType. This change replaces all such uses
with default surface properties with no special flags and an unknown
pixel geometry. Flutter never set the associated globals, leaving them
with their initial default values, which were no special flags and
horizontal RGB pixel geometry. The values used here are different but
this change should make no difference as Flutter never mentions
SkFont::kSubpixelAntiAlias to take advantage of the pixel geometry.
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.
Additionally create "_next" permutations for all of the test binaries
on Fuchsia, in order to test both code-paths.
Using the #define follow-up CLs can also create a flutter_runner_next
binary that does not contain any legacy integration code.
BUG: 53847
The way transactions were added changed in
8500bd4156.
This broke rendering using both Metal and OpenGL when no implicit transaction
was present on the transaction stack. The failure models differ based on Metal
vs. OpenGL and iOS/device versions. On older versions of iOS, rendering would
consume memory till exhaustion. On newer iOS versions, rendering would be stuck
(till a timeout). This patch brings transaction management back in line with as
it was earlier and also makes the Metal backend resilient to transactions being
present on the transaction stack at all. Since this is still quite brittle,
transaction management must be moved to IOSSurface as a followup.
Fixes https://github.com/flutter/flutter/issues/55784.
All Metal layers have their presentsWithTransaction property set to true.
However, when an external view embedder is not present, there is no mechanism to
ensure that the command buffer commit is within transaction scope. This works in
most cases as there there is usually an implicit (possibly nested) transaction
in place during rendering. However, when there isn’t, rendering will look paused
at an incorrect size. This code now works similar to OpenGL but will be
refactored for ease of understanding and consistency between the various
backends.
This moves the Metal `GrContext` creation utilities from `GPUSurfaceMetal` into
a separate `IOSContext` object subclass. An analogue of this object was used in
the GL regime for the management of onscreen and offscreen contexts that were
not tied to the lifecycle of the `GPUSurface`. This pattern has now been
generalized for use with all backends that need a resource context
(`IOSContextGL` and `IOContextMetal`).
The platform views controller management in the `ExternalViewEmbedder` interface
implementation was repeated three times for [Metal][metal], [OpenGL](opengl) and
[Software](software) rendering. This repetition has been removed and a single
implementation present in the base `IOSSurface` and used on all platforms.
Addition of new client rendering APIs should not affect how the engine renders
into the platform view interleaving levels.
All rendering API selection logic has been moved into a single set of utilities
in `rendering_api_selection.h`. This enables the removal of a lot of code blocks
guarded by `FLUTTER_SHELL_ENABLE_METAL`. The remaining uses of this will be
removed when unified builds are enabled.
The Metal backend now also adds traces similar to the GL backend.
The `IOGLContext` has been renamed to `IOContextGL` to be more in line with the
convention used in this library.
Fixes https://github.com/flutter/flutter/issues/41827
Adds https://github.com/flutter/flutter/issues/52150
[metal]: 46dbf3a761/shell/platform/darwin/ios/ios_surface_metal.mm (L55)
[opengl]: 46dbf3a761/shell/platform/darwin/ios/ios_surface_gl.mm (L95)
[software]: 46dbf3a761/shell/platform/darwin/ios/ios_surface_software.mm (L146)
This was only necessary when the Engine had to build in multiple buildroots
where the sources where checked out at different paths relative to the
buildroot. This is no longer the case and there are already cases GN rules
have been written that mix and match variable usage with the direct
specification of the path to the Flutter sources relative to the sole buildroot.
* Revert "Add flow test fixtures and tests (#13986)"
This reverts commit 32915132bacdfd0d631421b23bb6a6d5db1095ab.
* Revert "Dynamically determine whether to use offscreen surface based on need (#13976)"
This reverts commit a13401ce86b3019c39154d56644b7b9eb4a5bbe5.
This reverts commit 7552e9370527aae8df06b43dcb6b313d9ebdb365.
This is being reverted because it caused flutter/flutter#45098
(images don't load on iOS).
By default, the CAMetalLayer backing store is a framebuffer attachment that is
only optimized for display. However, effects such as backdrop filters require
renderbuffer readback. Making this calls will result in exceptions. Disable the
write only optimization on such backing store.
Fixes https://github.com/flutter/flutter/issues/43555
So it's the same with the GPU thread.
Otherwise, some shaders may be cached in binary on the IO thread, and we will lose them when we do the SkSL precompile.
For b/140174804
This patch allows embedders to split the Flutter layer tree into multiple
chunks. These chunks are meant to be composed one on top of another. This gives
embedders a chance to interleave their own contents between these chunks.
The Flutter embedder API already provides hooks for the specification of
textures for the Flutter engine to compose within its own hierarchy (for camera
feeds, video, etc..). However, not all embedders can render the contents of such
sources into textures the Flutter engine can accept. Moreover, this composition
model may have overheads that are non-trivial for certain use cases. In such
cases, the embedder may choose to specify multiple render target for Flutter to
render into instead of just one.
The use of this API allows embedders to perform composition very similar to the
iOS embedder. This composition model is used on that platform for the embedding
of UIKit view such and web view and map views within the Flutter hierarchy.
However, do note that iOS also has threading configurations that are currently
not available to custom embedders.
The embedder API updates in this patch are ABI stable and existing embedders
will continue to work are normal. For embedders that want to enable this
composition mode, the API is designed to make it easy to opt into the same in an
incremental manner.
Rendering of contents into the “root” rendering surface remains unchanged.
However, now the application can push “platform views” via a scene builder.
These platform views need to handled by a FlutterCompositor specified in a new
field at the end of the FlutterProjectArgs struct.
When a new platform view in introduced within the layer tree, the compositor
will ask the embedder to create a new render target for that platform view.
Render targets can currently be OpenGL framebuffers, OpenGL textures or software
buffers. The type of the render target returned by the embedder must be
compatible with the root render surface. That is, if the root render surface is
an OpenGL framebuffer, the render target for each platform view must either be a
texture or a framebuffer in the same OpenGL context. New render target types as
well as root renderers for newer APIs like Metal & Vulkan can and will be added
in the future. The addition of these APIs will be done in an ABI & API stable
manner.
As Flutter renders frames, it gives the embedder a callback with information
about the position of the various platform views in the effective hierarchy.
The embedder is then meant to put the contents of the render targets that it
setup and had previously given to the engine onto the screen (of course
interleaving the contents of the platform views).
Unit-tests have been added that test not only the structure and properties of
layer hierarchy given to the compositor, but also the contents of the texels
rendered by a test compositor using both the OpenGL and software rendering
backends.
Fixes b/132812775
Fixesflutter/flutter#35410
