This was already enabled by-default in AOT mode in [0] - which made the
gen_snapshot invocations use "--lazy-async-stacks --no-causal-async-stacks".
See go/dart-10x-faster-async for more information.
[0] https://github.com/flutter/flutter/commit/347823234fd
This reverts commit 6ea69a0d4339dd153899bb6c299689f1dd43329d.
On top of the revert, it reverted a commit in the PR:
https://github.com/flutter/engine/pull/14024
This reverts commit ea67e5b0b930ebf552bc7dbd678a35ee6a129c39.
This is a non-breaking addition to the stable Flutter Embedder API and exposes a
subset of the functionality provided by Dart_PostCObject API in a stable and
tested manner to custom embedder implementations.
Send port acquisition can currently be done as described in the unit-test but
there may be opportunities to extend this API in the future to access ports more
easily or create ports from the native side.
The following capabilities of the the Dart_PostCObject API are explicitly NOT
exposed:
* Object arrays: This allows callers to create complex object graphs but only
using the primitives specified in the native API. I could find no current use
case for this and would have made the implementation a lot more complex. This
is something we can add in the future if necessary however.
* Capabilities and ports: Again no use cases and I honestly I didn’t understand
how to use capabilities. If needed, these can be added at a later point by
appending to the union.
Fixes https://github.com/flutter/flutter/issues/46624
Fixes b/145982720
This makes it so that the platform views can be passed
an arbitraty CreateVsyncWaiter callback that lets us inject
a vsync waiter other than just the simulated monotonic vsync waiter
that currently exists.
The converters are still in a separate target that must be included manually. This allows targets that depend on FML but not Dart runtime not have to depend on the runtime.
Adds a test that includes this target and tests image decompression from assets. There is also a test for the standalone DartConvertor in shell_unittests but not in fml_unittests be cause FML uni-tests cannot yet launch a VM. I will work on adding fixtures for those.
This ensures we rasterize into the canvas passed in as subclasses may reimplement AcquireFrame in different ways that don't utilize the canvas object passed in (such as Fuchsia's flutter_runner::CompositorContext).
This reverts commit f456423cfb820d07bb36e9a8979e3d75cc9d8d76.
This is being reverted because it caused flutter/flutter#45098
(images don't load on iOS).
This re-enables thread safety checks for WeakPtr. WeakPtrs can't be used on a thread other than the one the WeakPtrFactory was created on.
This fixes the unit tests and adds a getUnsafe() method to WeakPtr to work around the remaining unresolved locations where we are using WeakPtr unsafely.
Since this is currently only meant to be used by the embedding internally, the setter in Objective-C is only exposed via the FlutterDartProject private class extension. Unit tests have been added to the shell_unittests harness.
Fixes https://github.com/flutter/flutter/issues/37641
Texture unregistration is finished on the GPU thread. The FlutterTexture implementation might not know when it is finished which leads to a race condition. Adding this callback so the FlutterTexture is aware of end of the unregistration process.
The rasterizer may only be accessed safely on the GPU task runner. The test was accessing the same on a non-engine known task runner instead (i.e the tests main task runner).
Crashes previously reproducible on all platforms with the following filters: `--gtest_filter="*ShellTest.SetResourceCacheSize*" --gtest_repeat=-1 --gtest_shuffle --gtest_random_seed=1988` at run ~400.
Fixes https://github.com/flutter/flutter/issues/37629
This should satisfy the low-latency need of DevTools.
Test added:
* ReportTimingsIsCalledSoonerInNonReleaseMode
* ReportTimingsIsCalledLaterInReleaseMode
Using it, a Flutter app can monitor missing frames in the release mode, and a custom Flutter runner (e.g., Fuchsia) can add a custom FrameRasterizedCallback.
Related issues:
https://github.com/flutter/flutter/issues/26154https://github.com/flutter/flutter/issues/31444https://github.com/flutter/flutter/issues/32447
Need review as soon as possible so we can merge this before the end of May to catch the milestone.
Tests added:
* NoNeedToReportTimingsByDefault
* NeedsReportTimingsIsSetWithCallback
* ReportTimingsIsCalled
* FrameRasterizedCallbackIsCalled
* FrameTimingSetsAndGetsProperly
* onReportTimings preserves callback zone
* FrameTiming.toString has the correct format
This will need a manual engine roll as the TestWindow defined in the framework needs to implement onReportTimings.
Some components in the Flutter engine were derived from the forked blink codebase. While the forked components have either been removed or rewritten, the use of the blink namespace has mostly (and inconsistently) remained. This renames the blink namesapce to flutter for consistency. There are no functional changes in this patch.
The reason we didn't merge just the gpu and platform threads from the get go was a deadlock in Shell:OnPlatformViewCreated and Shell:OnPlatformViewDestroyed.
The deadlock was caused by the platform thread starting a thread-hopping flow that ends ends up with the gpu thread releasing a latch that the platform thread is waiting on just after starting the cross-thread dance.
If the platform and gpu threads are the same, that last task that is posted to the gpu thread will never get executed as the gpu/platform thread is blocked on a latch.
This works around the deadlock by having a special case in the code for the scenario where the gpu and platform threads are the same.
Fixes: flutter/flutter#23974
Behavior (visual) changes should be very minor. Things that are to be expected:
* A few things were not color managed correctly by the transform canvas (color emoji, some color filters). Those will be handled correctly with the tagged surfaces (although we're always transforming to sRGB, so nothing should change until we target a wider gamut).
* Image filtering will happen in the source color space, rather than the destination. Very minor.
* The transform canvas did caching of images in the destination color space. Now, the conversion happens at draw time. If there are performance issues, images can be pre-converted to the destination with makeColorSpace().
