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.
Corects a bnuch of typeos throughout teh engien codebsae. Also makes
a couple minor Commonwealth -> US spelling adjustments for consistency
with the rest of Flutter's codebase.
Made use of `misspell` tool:
https://github.com/client9/misspell
If the mapping callback is not set or it the callback returns invalid data, ICU initialization will be embedder responsibility.
This affects all embedders and the following have been audited:
* Android: Via a symbol mapping.
* iOS: Via a file mapping.
* Embedder: Via a file mapping.
* Fuchsia: Via a VMO mapping
* Test shells and Flutter tester: Via file mapping with ICU data needing to be next to the executable.
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
Allow Flutter to automatically dump the skp that triggers new shader compilations. This is useful for writing custom ShaderWarmUp to reduce jank. By default, it's not enabled to reduce the overhead. This is only available in profile or debug build.
Later, we can add service protocol support to pull the skp from the client to the host. Currently, it works fine for Android-based devices (including our urgent internal clients) where we can `adb shell` into the cache directory.
The shell was already designed to cleanly shut down the VM but it couldnt
earlier as |Dart_Initialize| could never be called after a |Dart_Cleanup|. This
meant that shutting down an engine instance could not shut down the VM to save
memory because newly created engines in the process after that point couldn't
restart the VM. There can only be one VM running in a process at a time.
This patch separate the previous DartVM object into one that references a
running instance of the DartVM and a set of immutable dependencies that
components can reference even as the VM is shutting down.
Unit tests have been added to assert that non-overlapping engine launches use
difference VM instances.
Prior to this the Android embedder code would extract the icudtl.dat asset out
of the APK and write it to local disk during the first startup of the app.
This change will make that work unnecessary and eliminate the risk of ICU
failures due to errors in the extraction process.
The service protocol's ListViews method needs to return description data for
each engine in the process. Previously ListViews would queue a task to each
UI thread to gather this data. However, the UI thread might be blocked from
executing tasks (e.g. if the Dart isolate is paused), resulting in a deadlock.
This change provides a copy of the engine's description data to the
ServiceProtocol's global list of engines, allowing ListViews to run without
accessing any UI threads.
Fixes https://github.com/flutter/flutter/issues/24400
TL;DR: Offscreen surface is created on the render thread and device to host
transfer performed there before task completion on the UI thread.
While attempting to snapshot layer trees, the engine was attempting to use the
IO thread context. The reasoning was that this would be safe to do because any
textures uploaded to the GPU as a result of async texture upload would have
originated from this context and hence the handles would be valid in either
context. As it turns out, while the handles are valid, Skia does not support
this use-case because cross-context images transfer ownership of the image from
one context to another. So, when we made the hop from the UI thread to the IO
thread (for snapshotting), if either the UI or GPU threads released the last
reference to the texture backed image, the image would be invalid. This led to
such images being absent from the layer tree snapshot.
Simply referencing the images as they are being used on the IO thread is not
sufficient because accessing images on one context after their ownership has
already been transferred to another is not safe behavior (from Skia's
perspective, the handles are still valid in the sharegroup).
To work around these issues, it was decided that an offscreen render target
would be created on the render thread. The color attachment of this render
target could then be transferred as a cross context image to the IO thread for
the device to host tranfer.
Again, this is currently not quite possible because the only way to create
cross context images is from encoded data. Till Skia exposes the functionality
to create cross-context images from textures in one context, we do a device to
host transfer on the GPU thread. The side effect of this is that this is now
part of the frame workload (image compression, which dominate the wall time,
is still done of the IO thread).
A minor side effect of this patch is that the GPU latch needs to be waited on
before the UI thread tasks can be completed before shell initialization.
- Switch core snapshot to Dart 2 and remove support for loading platform.dill.
- Remove support for loading script snapshots.
- Remove support for loading source.
- Remove settings and fix names to reflect the above.
- Remove support for loading the service isolate from source.
