Prepare Flutter's Fuchsia port for removal of the
fuchsia.ui.app.ViewProvider.CreateView() API.
The Flutter engine's implementation of the API, which has long been
deprecated, is removed.
Calls to the deprecated CreateView() in tests are replaced with
CreateViewWithViewRef().
Bug fxbug.dev/81285
This CL changes ERROR to WARNING for the logs when a child disconnects
and ChildViewWatcher is closed. This may happen due to other apps and
doesn't necessarily indicate a flutter error.
Bug:fxb/125256
Resolves https://github.com/flutter/flutter/issues/124612.
Doing this would also allow us to remove the final blit on iOS when
advanced blends/backdrop filters are present (all of the facilities
would remain in place for GLES + Vulkan though).
Fixes https://github.com/flutter/flutter/issues/124269
Manually verified this is safe on an iPhone 11.
We're not creating/encoding command buffers in this path so it's ok.
AFAICT the test I added would fail if we started doing that because it
doesn't provide any real command buffer interfaces. Most of the code
here is related to tests.
Moves application termination handling to FlutterAppDelegate.
Previously, we required macOS applications using Flutter to ensure their
main application class was FlutterApplication. Instead, we now do all
handling in FlutterAppDelegate and FlutterEngine.
There are two termination workflows to consider:
* Termination requested from framework side: In this case, then engine
receives a `System.exitApplication` method call, and starts the app
termination workflow via `[FlutterEngine
requestApplicationTermination:exitType:result]`.
* Termination requested from macOS (e.g. Cmd-Q): In this case,
`FlutterAppDelegate`'s `applicationShouldTerminate:` handler is invoked
by AppKit, and the delegate starts the app termination workflow via
`[FlutterEngine requestApplicationTermination:exitType:result]`.
In either case, at this point, if the request is not cancellable, the
app immediately exits. If it is cancellable, the embedder sends a
`System.requestAppExit` method channel invocation to the framework,
which responds with either `exit` or `cancel`. In the case of `exit` we
immediately exit, otherwise we do nothing and the app continues running.
This is a minor refactoring of the original approach we took in:
https://github.com/flutter/engine/pull/39836
This does not remove the FlutterApplication class, since the framework
migration from NSApplication to FlutterApplication still depends on it.
A followup patch with replace the migration with a reverse migration
will land, then FlutterApplication will be removed.
Issue: https://github.com/flutter/flutter/issues/30735
No new tests since this refactors existing behaviour while retaining the
same app semantics as before.
With this approach, when the last window of an app is closed, the engine
sends a message to the framework to check if it is allowed to exit. If
it may, the windows lifecycle manager synthesizes a second `WM_CLOSE`
message that it will ignore, and so the next registered top level window
proc delegate, if any, will be able to process the message. If none do
so, the message will be handled by the default window proc, so the app
will be able to close.
I was not able to get a full system tray example application running to
test this, but I could get an application that stays open when its
window is closed and can be seen as a system tray icon as long as it is
running, albeit the icon was non-functional. As this repro app still
exhibited this behavior when using this engine build, I am reasonably
confident in concluding that applications that want to be able to run
headless when their windows close will function properly.
Addresses https://github.com/flutter/flutter/issues/123654.
## 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 Hixie said 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 `///`).
- [ ] 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
[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
---------
Co-authored-by: Loïc Sharma <737941+loic-sharma@users.noreply.github.com>
This PR makes view ID signed from unsigned int64.
Initially, I made view IDs unsigned because they were opaque anyway. As
I'm working deeper into multiview, I found some issues that made me
think signed is better:
* Unsigned integers are worse
* Sometimes you want negative values to represent special values.
* Unsigned integers are dangerous (if compared with signed ones by
mistake.)
* Unsigned integers are not needed
* We're very unlikely to reach that big anyway.
* Almost all other languages support only signed integers.
* Also JavaScript only supports up to 51 bits of integer.
Therefore I think it's better to change them to signed int64, especially
before these APIs are widely used by developers.
## 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 Hixie said 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
[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
This caused regressions for two internal customers.
Issue: https://github.com/flutter/flutter/issues/123654
Internal issue: b/275565297.
This reverts commit d7059df4ebe468913480f84d9d88832e89fc87d2.
* Fix mip-map generation in unit-tests where the command buffer was not
submitted.
* Cleanup descriptor counts being always 1 in Vulkan code-gen.
* Reworked capabilities. Platforms can add to the base capability set.
* Vulkan backend picks between more available color and stencil formats.
* Descriptor pools are dynamically sized.
* Layout transitions are more explicit. Both allocated and swapchain images
track their own layouts and redundant transitions are avoided.
* Objects active in a pending command buffer are collected but the waits happen
on a separate fence waiter. Thread is named
"io.flutter.impeller.fence_waiter".
* Added queue and command buffer instant markers for better traces.
* Command pools and their buffers are now thread local. Fixes sync validation
failure.
* Debug reports are now more readable and command buffer and queue breadcrumbs
will be displayed on a validation report.
* Staging buffers are back.
* Pipeline caches have been wired up. After 50 frames, the current Vulkan
pipeline cache will be written out to disk for subsequent launches. Writes
will happen on a background worker.
* Runtime stages have been wired up. But the build rules to provide the right
stages are still remaining.
Fixes https://github.com/flutter/flutter/issues/121536
Fixes https://github.com/flutter/flutter/issues/121627
Fixes https://github.com/flutter/flutter/issues/121632
Fixes https://github.com/flutter/flutter/issues/120499
