This is a reland of https://github.com/flutter/flutter/pull/177410
The previous pr was hitting deadlocks with tests that use screenshots.
This reland fixes it by submitting frames asynchronously instead of
synchronously.
This PR fixes https://github.com/flutter/flutter/issues/169147
This is the iOS implementation of
https://github.com/flutter/flutter/issues/149033
In Add-to-App scenarios, a common desired use case is to have the
embedded FlutterView be able to size itself based on it's content. Up
till now, the size had to be manually specified, which can be tedious
and inaccurate.
This PR adds a new flag, `isAutoResizable`, which enables the ability
for the embedded flutter view to dynamically set it's own size based off
it's content. Note that this feature will *NOT* work if the the embedded
app is wrapped in flexible or unsized widgets, such as Scaffold. The
FlutterView will just not display at all.
To use the new flag, just set it like
```
flutterViewController.autoResizable = true;
```
or in Swift
```
flutterViewController.isAutoResizable = true
```
## 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], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
Reverts flutter/flutter#177410
The change is causing the task `wide_gamut_ios` to hang every time.
Local testing shows that reverting this commit fixes the problem.
This PR fixes https://github.com/flutter/flutter/issues/169147
This is the iOS implementation of
https://github.com/flutter/flutter/issues/149033
In Add-to-App scenarios, a common desired use case is to have the
embedded FlutterView be able to size itself based on it's content. Up
till now, the size had to be manually specified, which can be tedious
and inaccurate.
This PR adds a new flag, `isAutoResizable`, which enables the ability
for the embedded flutter view to dynamically set it's own size based off
it's content. Note that this feature will *NOT* work if the the embedded
app is wrapped in flexible or unsized widgets, such as Scaffold. The
FlutterView will just not display at all.
To use the new flag, just set it like
```
flutterViewController.autoResizable = true;
```
or in Swift
```
flutterViewController.isAutoResizable = true
```
## 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], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
This also moves the Abseil sources from //flutter/third_party to
//third_party to allow use of Chromium's GN scripts without
modification.
See internal issue b/400498305
This depends on the implicitly generated `operator!=` from `operator==`
in a few cases (see the exceptions below) and add `operator<=>` in some
of the more obvious instances.
I've tried to be extremely conservative in this first pass. There are a
few more candidates that were not converted because:
* `operator!=` was different from `!operator=.` For instance, if it had
early returns. Not sure how the compiler generated those and didn't want
the behavior or performance characteristics to change.
* They were virtual.
* `operator==` didn't actually compare all struct members. Dubious but I
didn't want to change existing behavior.
* There were template parameters.
Earlier, it was just a comment. If you didn't do what the comment said,
you'd get a mysterious compiler error when the template was instantiated
at the point where the trait method was invoked. This would be extremely
far away from where the template was instantiated and typically in
`fml/unique_object.h`.
Now, the exact reason and where a fix would go is printed in the
compiler error. For instance, if I delete the Free method in
`UniqueDirTraits`, I get (among other output):
```
no member named 'Free' in 'fml::internal::os_unix::UniqueDirTraits'
```
The changes:
* Creating a bit-mask with different enum values is now a warning. Fixed
offending instances.
* `char8_t` is a different type. Fixed those instances.
* Disabling modules in Objective-C requires bypassing the driver.
* Aggregate initialization fails when there are other constructors for
structs. Added explicit constructors.
* `gn format` doesn't seem to be run on erstwhile buildroot GN files.
Fixes the formatting. But can back this out since it is technically
unrelated to C++20.
This PR refactors the skwasm renderer to use `DisplayList` objects as
its main model objects instead of using Skia objects directly. Then, at
render time, we dispatch the display list commands to the skia surface.
This is a preparatory step for impeller on web.
* Some build rules were reworked in order to allow `DisplayList` to
compile via emscripten
* Some pieces of the display list library were further refactored to
allow us to compile it without actually building and linking the
impeller shaders. The two major classes that needed to be separated out
were `DlRuntimeEffect` and the text drawing system.
* `SkPath` and `SkImage` are still used as the main model objects in
skwasm. As of right now, `DisplayList` just thinly wraps these objects,
so this is the minimal possible change for now. I will have to refactor
this somewhat further when preparing for actual impeller adoption.
* Several special cased code paths in skwasm were removed, as they are
taken care of by `DisplayList` itself. This includes shadow drawing,
determining when to enable dithering, and determining the right clamp
value for filters.
This makes two refactors to the display list architecture:
* The concrete implementations of `DlRuntimeEffect` for skia and
impeller are separated, and the impeller implementation put into the
`impeller/display_list` target. This makes sure that a client can link
against the main `display_list` library without actually pulling in all
of impeller. (This is needed for
https://github.com/flutter/flutter/pull/172314)
* The `DrawTextBlob` and `DrawTextFrame` methods are consolidated into
one `DrawText` call, and that takes a `DlText` object. The `DlText`
object has two implementations, one for skia and one for impeller, and
the impeller one is moved into `impeller/display_list` for the same
reason mentioned above.
The pattern is similar to the recently added WASM (and previously NACL)
toolchains.
The major change is the engines use of functions that became constexpr
in C++26 (such as
[sqrt](https://en.cppreference.com/w/cpp/numeric/math/sqrt)) as if they
were already constexpr. I have attempted to keep the linkage the same
and am investigating how to enable this form of checking with our own
toolchain.
This includes a fix for a race seen in
EmbedderTest.PlatformThreadIsolatesWithCustomPlatformTaskRunner
The implementaion of MergedPlatformUIThread::kMergeAfterLaunch required
changing the interface of the TaskObserverAdd/TaskObserverRemove
callbacks so that TaskObserverAdd returned the TaskQueueId where the
observer was added. That TaskQueueId would later be given to
TaskObserverRemove.
The original implementation of this PR updated the embedder library's
implementation of TaskObserverAdd to return TaskQueueId::kInvalid to
signal that the observer was not added. However, this conflicted with
the embedder's EmbedderTaskRunner, whose implementation of
GetTaskQueueId returns TaskQueueId::kInvalid as a placeholder.
This PR reverts the embedder's TaskObserverAdd/TaskObserverRemove to the
original implementation which adds the observer to the current thread's
message loop and does not call GetTaskQueueId.
See https://github.com/flutter/flutter/issues/167418
If settings.merged_platform_ui_thread is set to kMergeAfterLaunch, then
the engine will be started on the UI thread. After engine setup
completes and the Dart isolate is loaded, the UI task runner will be
merged into the platform thread and all future Dart execution will run
on the platform thread.
This makes it possible for other work to run on the platform thread
while the engine starts.
See https://github.com/flutter/flutter/issues/163064
Changes required for this roll:
* addition of LLVM libc (which is now a dependency of libcxx)
* updates the to license script
* patching the verify_exported check to allow some symbols added by
libcxx
* annotations for clang-tidy warnings
Asking if the logs should be emitted and killing the process (say on
unreachable statements) wasn't constexpr. However we managed to use
these in constexpr contexts. As I understand, this was because of
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2448r2.html
which is available in C++23. This technique makes the methods constexpr
safe in C++17.
This was likely a holdover from a time when trace events were routed to
the timeline directly.
This was causing standalone QNX builds to also pull in Dart.
No change in functionality and hopefully faster builds for smaller
targets.
Changes the following shell callbacks to flush the dart event loop:
* OnPlatformViewSetViewportMetrics
* OnPlatformViewDispatchPointerDataPacket
* OnPlatformViewDispatchPlatformMessage
* OnPlatformViewSetSemanticsEnabled
* OnPlatformViewSetAccessibilityFeatures
Using a new TaskRunner API RunNowAndFlushMessages. If the task runner can run tasks on the current thread, this will immediately invoke a callback and then post an empty task to the event loop to ensure dart listeners fire.
Unlike https://github.com/flutter/engine/pull/56738, does not touch the vsync API - which looks like it depends on scheduling behavior today, at least for iOS.
Reverts: flutter/engine#56738
Initiated by: jonahwilliams
Reason for reverting: speculative revert for framework failures.
Original PR Author: jonahwilliams
Reviewed By: {jason-simmons}
This change reverts the following previous change:
Changes the following shell callbacks to flush the dart event loop:
* OnPlatformViewSetViewportMetrics
* OnPlatformViewDispatchPointerDataPacket
* OnPlatformViewDispatchPlatformMessage
* OnPlatformViewSetSemanticsEnabled
* OnPlatformViewSetAccessibilityFeatures
Using a new TaskRunner API RunNowAndFlushMessages. If the task runner can run tasks on the current thread, this will immediately invoke a callback and then post an empty task to the event loop to ensure dart listeners fire.
This also updates the vsync waiter to use RunNowOrPostTask, so that we start vsync events as early as possible.
Changes the following shell callbacks to flush the dart event loop:
* OnPlatformViewSetViewportMetrics
* OnPlatformViewDispatchPointerDataPacket
* OnPlatformViewDispatchPlatformMessage
* OnPlatformViewSetSemanticsEnabled
* OnPlatformViewSetAccessibilityFeatures
Using a new TaskRunner API RunNowAndFlushMessages. If the task runner can run tasks on the current thread, this will immediately invoke a callback and then post an empty task to the event loop to ensure dart listeners fire.
This also updates the vsync waiter to use RunNowOrPostTask, so that we start vsync events as early as possible.
Enables the `-fobjc-arc` compiler flag for Objective-C and Objective-C++
translation units.
Eliminates the flutter_cflags_objc[c]_arc settings, since they're now
redundant.
All Obj-C/Obj-C++ code in our codebase has now been migrated to ARC.
Issue: https://github.com/flutter/flutter/issues/137801
`fml::CFRef` implements the bulk of the operations implemented in the one-off `Scoped` class except with better safety guarantees such as `[[nodiscard]]` on the `Release` method. It doesn't implement the `handle()` method that allows direct writing into the internal storage of the wrapper, but that method is effectively an escape hatch for all the safety guarantees provided by the wrapper, so it seems safer to avoid adding it.
No changes to tests since this includes no semantic changes.
Issue: https://github.com/flutter/flutter/issues/137801
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Document where CFRef takes over or hands back ownership of the underlying CoreFoundation object memory.
Migrates manual CoreFoundation object management to CFRef in:
* impeller/golden_tests/metal_screenshot.mm
* shell/platform/darwin/graphics/FlutterDarwinContextMetalSkia.mm
* shell/platform/darwin/graphics/FlutterDarwinExternalTextureMetal.mm
* shell/platform/darwin/ios/framework/Source/FlutterView.mm
* shell/platform/darwin/macos/framework/Source/FlutterSurface.mm
Adds a `Retain()` method to take shared ownership of the underlying object, as opposed to Reset, where ownership is transferred to the CFRef wrapper.
Adds a `Get()` method to make dealing with bridged Objective-C casts more convenient:
```objc
fml::CFRef<CFStringRef> cfString(...);
NSString* aString = (__bridge NSString*)cfString.Get();
```
as opposed to:
```objc
fml::CFRef<CFStringRef> cfString(...);
NSString* aString = (__bridge NSString*)static_cast<CFStringRef>(cfString);
```
I considered making use of `fml::scoped_policy::OwnershipPolicy` to add a second parameter to the ctor and `Reset` but, but I think documentation and addition of a `Retain()` method makes things a little clearer at the call site. It's also more consistent with `sk_cfp`, which we use in some Skia bits of the codebase.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Eliminates the two remaining uses of ScopedBlock and with it, ScopedTypeRef which was only used by ScopedBlock. ARC automatically generates the necessary block copy/retain/release calls, including moving blocks to the heap during a retain so manual _Block_copy/_Block_release calls are no longer required.
No test changes since no semantic changes.
Issue: https://github.com/flutter/flutter/issues/137801
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Ensure that all Objective-C code in the codebase is being built with the standard set of Flutter Objective-C compiler flags with ARC enabled.
Also bumps the cflags config up to the top of the first block within each target in which Objective-C sources appear, so that the location is consistent.
Migrates The following targets to ARC, which had been missed in previous passes since they didn't declare the standard Flutter Obj-C[++] cflags:
* `//flutter/fml:fml_unittests`
* `//flutter/impeller/golden_tests:metal_screenshot`
* `//flutter/impeller/playground:playground`
* `//flutter/impeller/backend/metal:metal`
* `//flutter/impeller/backend/metal:metal_unittests`
* `//shell/gpu:gpu_surface_metal_unittests`
* `//flutter/shell/platform/embedder:embedder_unittests`
This patch includes no semantic changes.
Issue: https://github.com/flutter/flutter/issues/137801
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
fml::scoped_nsobject and fml::scoped_nsprotocol classes are no longer
necessary now that the entire codebase has been migrated to ARC.
This also eliminates the fml_arc_unittests target which tests that code.
All references to that target in documentation, run_tests.py have been
removed. This target was used in various `et` build/query unit tests and
has been replaced with the fml_unittests target in those cases.
Issue: https://github.com/flutter/flutter/issues/137801
This issue was found with memory sanitizer.
Commit 988c4ffb83398bf8511122d73f0f85010e0edeea introduced a change that leads to use-after-free condition.
In function MessageLoopTaskQueues::GetNextTaskToRun:
1) Call is made to PeekNextTaskUnlocked(queue_id);. Returned value contains a reference to to an object of const DelayedTask& taken from an std::queue container as returned by primary_task_queue_.top().
2) Variable TaskSource::TopTask top now contains a reference to this object.
3) Function queue_entries_.at(top.task_queue_id)->task_source->PopTask(...) which in turn calls pop() method on std::queue.
4) Object of type DelayedTask on top of the queue gets deleted.
5) top.task.GetTaskSourceGrade() is called later with top.task refering to an already deleted object.
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Some android devices have only a single fast core. We set the threading affinity for UI/Raster to the fast core, which can lead to the UI/Raster being serialized on this thread. Instead, we should weaken /invert the affinity to "Not slow cores".
FIxes https://github.com/flutter/flutter/issues/153690
Customer money will see some benchmark regressions but they can deal.
We used to require this only on iOS because the standard library till iOS 9 didn't have support for this. We have moved past that version. No change on other platforms.
Fixes Impeller engine build with `clang-16` and GCC 14 C++Stdlib does not implicitly include `<algorithm>`.
Fixes issue: #150515
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Reverts flutter/engine#53136
b/345642546 shows some massive performance regressions on this patch. i'll rework it so the conditions are only loosened on phones with one fast core.
For devices with 1 fast core, the current affinity set is less idea because it forces UI and raster on the same thread. Widen this to exclude slow cores instead of including only the fast core.
Previously, because the suppression was local, every user of the the header had to manually add the flag. Now the flag will be propagated to the targets automatically. This linked issue still needs to be fixed but the fix can now be more isolated.
