Now you can use --snapshot to load snapshots from the command line and have
them appear visually on Mac. Also, remove code duplication with Linux by
factoring common testing code into //sky/shell/testing.

Looks like the Keyboard service is only for iOS. We shouldn't try to build it
on Mac.

We used to do this in the SkPicture, but it's simpler to do it in the
rasterizer now that we're using multiple SkPictures in Dart.

traces from base and the shell view dart isolate simultaneously.
Trace files contain samples from multiple sources and must be merged
separately

http://developer.android.com/reference/android/view/View.html#onCheckIsTextEditor()
says that we should return true if the "primary purpose" of
the view is text editing.  The keyboard still seems to work
fine if we return false here (default implementation) so
I'm removing this for now.

Fixes https://github.com/domokit/sky_engine/issues/116

@abarth

This patch simplifies the SkPicture we generate for Skia. Instead of drawing
everything into a nested SkPicture, we now draw everything into the top-level
picture, which requires us to apply the device scale factor in Dart.

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

The --checked argument runs SkyShell in checked mode, which turns on type
checking and asserts.

@abarth

 - Make space for the iOS status bar.
 - Set the iOS status bar to use white text.

app.skyx file in DEBUG mode.

directory on the device.

This work is to support a workflow where developers testing on an iOS
device will automatically see their app updates as they change their Sky
code. Currently this works by using the ios-deploy tool:
$ ios-deploy --bundle_id 'org.domokit.sky.game' --upload out/ios_Debug/game_app.app/app.skyx --to Documents/app.skyx
Upcoming commits will incorporate this into skytool.

@chinmaygarde

We need a way for developers to use release builds in checked mode.

Progress on #400

@abarth

@abarth

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

This was likely a race which caused occasional timeouts.

R=abarth@google.com

Also, make the initialization order the same on every platform.

The previous implementation would (silently) delete any previous
ServiceProviderImpl which would close all open mojo pipes.
This would manfiest in the mojo:network_service never
responding to Dart's request for loads.

This mostly fixes issue #256, however there still appears to be
a separate display-only race, which may be related to issue #52.

R=abarth@google.com

It was looking for the wrong executable name.

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.

On iOS as soon as a gesture recognizer takes over it cancels all outstanding
touches.

R=@abarth

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.

@chinmaygarde