Pipelines vend single use continuations that callers can complete at any time to signal readiness of a pipeline resource. (#2957)

If the vsync provider is being replaced, make sure the animator expects no more signals from the old registration. (#2954)

Make the animator host an implicit fallback VSync provider in case platforms cant provide their own. (#2953)

Also, rename SkyViewClient to RuntimeDelegate. These names are more
sensible.

This patch also cleans up the RuntimeDelegate a bit, for example by
removing support for flushing real-time events, which aren't used.

This patch removes almost all //base dependency of //flow. The only dependency
left is on tracing.

* Update to mojo 7d579155cc597aa3befcbfad66eef54bda06b57c

* Update to new API

Improve tracing in graphics stack, esp on Mojo

Previously we would hold the layer tree until the we returned from Dart. Now we
send the layer tree to the rasterizer thread immediately.

Fixes #212

Fixes #1499

When the engine starts a new version of the Dart application, the animator may
have pending callbacks and other state related to the previous run of the app.
This state must be cleared before the new vsync provider is assigned.

Everything should work except the keyboard.

We now use std::unique_ptr more consistently.

Now that the compositor doesn't have any tricky deps, we can make it a
top-level project, which saves a bunch of typing.

Instead of spamming the MessageLoop, guess that 16ms is a good amount of
time to wait

Fix https://github.com/flutter/flutter/issues/371 renaming "sky" and "chromium" to "flutter" in logs and Mac Shell UI

After this patch, we can execute Dart code and draw the result via MGL. We
still need to plumb in services.

dont mutate from frame to frame

Instead of squashing the layers down into a single SkPicture, we now pass the
tree to the GPU thread, which draws everything separately.

Previously we were using the cull rect of the SkPicture to size the GPU buffer,
but Skia is too smart and shrinkwraps the cull rect, which meant we weren't
sizing the GPU buffer to the right size.

Fixes #814

Now that we can use WTF everywhere, we don't need to use skia::RefPtr.

@abarth

Now we actually use the vsync signal to trigger work. Previously, we'd hit the
pipeline depth limit too early and fall back to swap buffers-triggered
rendering.

Also, rename Vsync to VSync on recommendation from jamesr.

Instead of using back pressure from swap buffers to drive the engine, this
patch using the vsync signal from the Android framework. We still respect
back pressure from swap buffers if we get too far ahead.

Previously, there was a race condition whereby we could end up with three
requests in the pipeline. Now we update the number of outstanding requests
synchronously, which avoids the race.

This DCHECK is triggering due to my recent change. Remove it while I debug.

Previously, we weren't overlapping any work between the UI and the GPU threads
because each waited for the other to finish. After this patch, we now have a
pipeline depth of 2, which means we can be working on two frames at once, one
for each thread.  In the future, we should dynamically adjust the pipeline
depth.

This listens to both surface destruction as well as activity
pause/unpause.

R=abarth@chromium.org, abarth@google.com

Review URL: https://codereview.chromium.org/1230073002 .

This CL adds trace events:

1) Between requesting a frame and begin frame.
2) In the DartLoader see network latency.
3) While executing |main| and |_init|.

TBR=eseidel@chromium.org

Review URL: https://codereview.chromium.org/1025073003

However WebView::close() no longer crashes.  close() is never called
in MojoShell since mojo can't shutdown yet.

I tried closing the existing WebView and replacing it
but somehow that caused it to only draw red.  After a while
of looking at this with abarth we decided to just load into
the same WebView for now.

Eventually we should do something smarter where we start the
provisional load and only replace the webview once the new one is
ready, but that's a later CL.

R=abarth@chromium.org
BUG=

Review URL: https://codereview.chromium.org/952273003

This CL contains enough plumbing for Sky to render content to the screen using
Ganesh in SkyShell. We're still missing the ability to load data off the
network.

R=eseidel@chromium.org, ojan@chromium.org

Review URL: https://codereview.chromium.org/936883002