This include build system changes for selecting Dart's precompiler mode
plus a way to locate and load the precompiled snapshot library from an
Android application
Dart invokes Start/StopTracing callbacks within the _setVMTimelineFlags service
method whenever the embedder timeline stream toggles on or off. Flutter's
implementation of these callbacks was modifying the set of enabled streams,
which could override the intended behavior of _setVMTimelineFlags.
Start/StopTracing will now only control Flutter's embedder-specific log.
Also needed to change the Flutter engine's --trace-startup flag to set the
corresponding timeline stream flag on the Dart VM.
This complex machinery made sense for Blink, which has hundreds of
developers. In our case, we're just moving around two bools. We can do
that in a much simpler way.
Now the control flow for wiring up platform services starts in the
platform-specific code. Previously we started in shared code, which was
imposing constraints on the startup sequence for all platforms. Now that we
start in platform-specific code, we'll be able to add better support for Mojo
in a future patch.
Currently we run some tasks on the UI thread that shouldn't block the frame,
such as decoding images. This patch introduces a background thread on which we
can run these tasks.
This updates to mojo 4e4d51ce28a and mojo sdk 711a0bcfb141b4 and updates the sky
package's pubspec.yaml dependency to '>=0.1.0 <0.2.0' to be compatible with
the current mojo package. This includes an update to the Mojo Dart generator to
produce real classes for enums and the corresponding updates for users of the
KeyboardType enum in Sky as well as one scoped_ptr->std::unique_ptr in shell
corresponding to a change in the Mojo EDK.
When a new version of the sky and sky_services package are pushed this will fix
domokit/mojo#440.
This updates to mojo commit d259eb58aa59 and limits the roll script to
only pull in the parts of //mojo that are currently being used. More
stuff will be dropped in the future.
Apparently this can cause a crash when when we try to render an emoji at a
different size than the emoji font's native bitmap size. I'm not sure how to
reproduce the issue. I'll ask Hixie when he gets back.
Currently we just use regular memory. In the future, we should actually use
discarable memory.
Fixes#203
