This doesn't yet add support for backdrop filters or emulated advanced blends, but will allow them to work if `surface_frame.framebuffer_info().supports_readback` is true.
part of https://github.com/flutter/flutter/issues/142054
Resolves https://github.com/flutter/flutter/issues/134748.
This was a really fun experiment. I learned a lot from it, and it genuinely helped me solve some coverage-related problems, but the reality is it was too little too late -- by the time we had this capture system, we had already solved most of the problems that would have benefitted from this.
It's been a few months since I've used or extended the capabilities of this capture system for something, and I don't have the spare time/energy to give it the love it needs to realize the vision I had for it. I still almost exclusively use a combination of native frame captures and print debugging to solve problems.
RIP in peace.
The observed behavior is that if a keypress both reach framework and flutter textinputplugin selector and the keypress handler in framework causes the the textinputplugin to resign first responder, the selector will still go through even if the textinputplugin has already resigned.
The pr makes it so textinputplugin will ignore these selector call
fixes https://github.com/flutter/flutter/issues/143270
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This wires up Android Hardware Buffer backed swapchains on platform that support
it (Android >= 29) with a KHR swapchain fallback (which can be removed later to
save on some binary size if needed).
Some salient features of these swapchains and their differences with the KHR
variant:
* All swapchain images are guaranteed to R8G8B8A8. This could potentially allow
for earlier creation of the context and the PSO libraries.
* All swapchain allocations are lazy. This should greatly reduce the time it
takes to create and resize a swapchain. However, swapchain image acquisition
may take longer for the first few frame where there is no pre-pooled image
available. Resizes should be similarly faster since the swapchain images for
the intermediate sizes are never created.
* Swapchain transients allocations (the attachments for the root render target)
are also lazily allocated.
* Swapchain images are pool and reused. The size of the pool is user specified
(currently 2). If an image in the pool ages past a user supplied value
(currently 1 second), it is collected as well. Applications that don't render
frames for a long period of time should see less memory use because of
swapchain image allocations.
* The present mode of AHB swapchains behave similar to KHR swapchains but with
VK_PRESENT_MODE_MAILBOX_KHR. In cases where there is no application managed
frame pipelining, this might cause images to never be presented if a newer
image is available. This wasted work can only be avoided by application
provided pipelining.
* There are no client side waits during image presentation. Instead, a new type
of fence is wired up that exports its state as a sync file descriptor. The
fence signal operation is enqueued on the client side and the buffer is set on
the surface control. The presentation engine then performs the wait.
* On Qualcomm devices, Chromium seems to be setting vendor specified flags for
opting the hardware buffers into using UBWC. AFAICT, this is similar to AFBC
(and NOT AFRC) on ARM Mali. This has not been wired up since I don't have a
Qualcomm device at the moment and cant verify bandwidth use using GPU
counters. I would also like to verify that UBWC is safe to use to images that
can be used as input attachments.
This removes goma most places except for the arguments to the `gn`
script, which are referenced by recipes. This does not remove goma
capabilities from the GN build entirely. That requires changes in the
buildroot which have to be staged after this change.
This is a refactor that moves the `PointerDataPacketConverter` from `PlatformView` to `RuntimeController`.
This change is made for the following reasons:
- Currently, the pointer data conversion contains no platform specific logic (because the current converter's only responsibility is to make the event sequence conform Flutter's protocol). Therefore these logics should reside in a platform-independent place.
- The converter typically converts one event to many. It's better to have this conversion later than earlier.
- It removes a member from `PlatformView`, making it closer to a pure virtual class.
The reason to choose `RuntimeController` as the destination is because `RuntimeController` manages a map for views, which is required for the converter to implement a later patch https://github.com/flutter/engine/pull/51925.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Fuchsia's fake-display will be migrating to sysmem2, which requires fuchsia.sysmem2.Allocator to be routed in a few places.
fixesflutter/flutter#146858
- [y] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
- [y] I read the [Tree Hygiene] wiki page, which explains my responsibilities.
- [na] I read and followed the [Flutter Style Guide] and the [C++, Objective-C, Java style guides].
- [y] I listed at least one issue that this PR fixes in the description above.
- [fixes to existing tests] I added new tests to check the change I am making or feature I am adding, or the PR is [test-exempt]. See [testing the engine] for instructions on writing and running engine tests.
- [na] I updated/added relevant documentation (doc comments with `///`).
- [na / googler] I signed the [CLA].
- [y] All existing and new tests are passing.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The latest version of Clang is reporting warnings from the -Wcast-function-type-mismatch check when a function taking a __strong pointer parameter is converted to a void* parameter.
This stub PR removes and extra `setViewController`, which is unnecessary because the view controller's initializer already attaches itself to the engine.
This PR also removes an extra import since `FlutterCompositor` is not used in the engine's definition. As a result, `FlutterEngineTest.mm` needs to import it explicitly.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
CVPixelBuffers from the application can have arbitrary pixel formats. However, current implementation doesn't support all pixel formats. To address this, add a comment to the FlutterTexture class to clarify which pixel formats are supported. Also, reject unsupported pixel formats so that the application can handle them properly.
Fixes [#147242](https://github.com/flutter/flutter/issues/147242).
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Trying to migrate the iOS embedder MRC to ARC, I'm attempting to break some dependency cycles so it's easier to migrate the "leaf" dependencies to ARC, working my way up.
The cycle is:
**`FlutterViewController`** -> `FlutterView` -> `FlutterPlatformView` -> (Before this PR)**`FlutterViewController`**
`FlutterViewController` depends on many other large MRC classes, like FlutterEngine., so I'd like to pull that one out so `FlutterView`, `FlutterPlatformView`, and `FlutterOverlayView` can be migrated to ARC in a smaller PR.
`FlutterPlatformView` only depends on `FlutterViewController` in this one place, casting a `UIViewController` and calling `-forceTouchesCancelled:`.
0e6143504c/shell/platform/darwin/ios/framework/Source/FlutterPlatformViews.mm (L1201)
Instead, move `-forceTouchesCancelled:` to the existing `FlutterViewResponder` protocol with the other touch events, which `FlutterViewController` already implements. The cast can then be removed, breaking the cycle.
Clean up all the imports.
Part of https://github.com/flutter/flutter/issues/137801, though this doesn't actually migrate anything to ARC.
Smart pointers support ARC as of https://github.com/flutter/engine/pull/47612, and the unit tests were migrated in https://github.com/flutter/engine/pull/48162.
Migrate `FlutterUndoManagerPlugin` from MRC to ARC.
1. Refactor so the plugin and its tests don't need to understand the details of `FlutterViewController` or `FlutterEngine` (its delegate). This decouples the plugin, and means it doesn't depend on any MRC classes.
2. Change the delegate so conforming only requires the objects the undo plugin actually needs.
Part of https://github.com/flutter/flutter/issues/137801.
This PR adds `FlutterViewController` with new API `viewIdentifier` and
renames all occasions that mention "viewId" to "viewIdentifier", to
align with the requirement for the iOS shell.
A new typedef `FlutterViewIdentifier` is also added. ~~The problem is,
we don't have a file to contain this typedef. Currently I put them in a
new file called `common.h`. I'm open to other suggestions.~~ It has been
moved to `FlutterViewController.h`.
* Another alternative is to not use the type def, but use `int64_t`
directly. I'm ok with this choice too, since honestly it's just a 64
int.
Also, macOS's definition for `kFlutterImplicitViewId` has been removed
in favor of the one in `common/constants.h`.
## Pre-launch Checklist
- [ ] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [ ] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [ ] I read and followed the [Flutter Style Guide] and the [C++,
Objective-C, Java style guides].
- [ ] I listed at least one issue that this PR fixes in the description
above.
- [ ] I added new tests to check the change I am making or feature I am
adding, or the PR is [test-exempt]. See [testing the engine] for
instructions on writing and running engine tests.
- [ ] I updated/added relevant documentation (doc comments with `///`).
- [ ] I signed the [CLA].
- [ ] All existing and new tests are passing.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#overview
[Tree Hygiene]: https://github.com/flutter/flutter/wiki/Tree-hygiene
[test-exempt]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo
[C++, Objective-C, Java style guides]:
https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
[testing the engine]:
https://github.com/flutter/flutter/wiki/Testing-the-engine
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes
[Discord]: https://github.com/flutter/flutter/wiki/Chat
Canvas implementation that renders directly, requires ENABLE_EXPERIMENTAL_CANVAS to be set to true and only wired up for android/vulkan.
Currently missing:
* Clips
* backdrop filters
* opacity peephole
* More?
This will eventually allow us to delete the aiks layer and cut out most conversion costs. Part of https://github.com/flutter/flutter/issues/142054
Fixes https://github.com/flutter/flutter/issues/138936
Currently the engine hold a single backbuffer per flutter view layer,
which gets swapped with front buffer. This however is too optimistic, as
the front buffer in some cases might not get immediately picked up by
the compositor. When that happens, during next frame the cache may
return a backbuffer that is in fact still being used by the compositor.
Rendering to such surface will result in artifacts seen in the video.
This seems more likely to happen with busy platform thread. It is also
more likely to happen with the presence of "heavy" platform views such
as `WKWebView`.
IOSurface is able to report when it is being used by the compositor
(`IOSurfaceIsInUse`). This PR ensures that the backing store cache never
returns surface that is being used by compositor. This may result in
transiently keeping more surfaces than before, as the compositor
sometimes seems to holds on to the surface longer than it is displayed,
but that's preferable outcome to visual glitches.
This PR adds `age` field to `FlutterSurface`. When returning buffers to
the surface cache (during compositor commit), the age of each surface
currently present in cache increases by one, while the newly returned
surfaces have their age set to 0.
When returning surfaces from cache, a surface with lowest age that is
not in use by compositor is returned.
Surfaces with age that reaches 30 are evicted from the pool. Reaching
this age means one of two things:
- When surface is still in use at age 30 it means the compositor is
holding on to it much longer than we expect. In this case just forget
about the surface, we can't really do anything about it.
- When surface is not in use at age 30, it means it hasn't been removed
from cache for 29 subsequent frames. That means the cache is holding more
surfaces than needed.
Removing all surfaces from cache after idle period remains unchanged.
Before:
https://github.com/flutter/engine/assets/96958/ba2bfc43-525e-4a88-b37c-61842994d3bc
After:
https://github.com/flutter/engine/assets/96958/8b5d393e-3031-46b1-b3f0-cb7f63f8d960
*If you had to change anything in the [flutter/tests] repo, include a
link to the migration guide as per the [breaking change policy].*
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide] and the [C++,
Objective-C, Java style guides].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I added new tests to check the change I am making or feature I am
adding, or the PR is [test-exempt]. See [testing the engine] for
instructions on writing and running engine tests.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I signed the [CLA].
- [x] All existing and new tests are passing.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#overview
[Tree Hygiene]: https://github.com/flutter/flutter/wiki/Tree-hygiene
[test-exempt]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo
[C++, Objective-C, Java style guides]:
https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
[testing the engine]:
https://github.com/flutter/flutter/wiki/Testing-the-engine
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes
[Discord]: https://github.com/flutter/flutter/wiki/Chat
Part of https://github.com/flutter/flutter/issues/145729 .
I don't believe (or wasn't able to find ) if there is a way to specify dart-vm flags from an iOS application. Once its installed, the tool provided process args won't work. By allowing this to be specified in the Plist, developers can ensure the value persists for subsequent launches.
