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.
* Reland "Added IsolateNameServer functionality (#5410)"
This reverts commit c3976b3c71.
* Fixed issue with isolate_name_server_test which caused test to timeout
* Disabled thread_annotations on Android as they aren't supported in the
NDK headers for std::mutex. Readded thread annotations to
IsolateNameServer.
* Added IsolateNameServer functionality, which allows for the association
of string names with isolate SendPort ids that can be used to establish
inter-isolate communications.
The mobile shells all use the same isolate snapshot. This is also the snapshot used by the service isolate. This works towards a world where the isolate snapshot is no longer a member variable of the DartVM instance. Instead, all snapshots must be specified in the run configuration. For now, the new `Shell::Create` overload will only be used by Fuchsia till I refactor `dart_vm.cc`.
There are no API updates to the mobile shells.
Isolates may be launched and awaiting snapshot association. We don't
want to send such isolates any messages before their "main" method is
called. In such cases, the engine may intercept and store certain
launch specific information.
Dan Field
Zachary Anderson
Chinmay Garde
Gary Qian
Jason Simmons
Michael Goderbauer
Michael Klimushyn
Jonah Williams
Ben Konyi
Ryan Macnak