1) Factors InkWell out of Material so that components can use an ink well
without needing the shadow/level machinery.
2) Makes the ink effect move at a different velocity once the tap has actually
occurred, converging with the spec. We don't have the right speeds yet, but
at least we're approaching the right shape.
3) To support (2), added a primaryPointer attribute to GestureEvents to let
authors coorelate gesturetapdown events with later gesturetap events.
4) To support (2), modernized SplashAnimation to used AnimatedValue and friends.
5) Added more constants to view-configuration.dart that match Android.
I've also removed the cancelling of the ink effect on scroll. The proper way to
do that is to notice that someone in the event chain is listening for
scrollstart and delay the beginning of the ink effect for some period of time.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1019023003
Previously, we weren't scheduling a visual update when our surface was created,
so we'd just continue to show black until the author requested a new animation
frame. After this CL, we schedule a visual update as soon as our surface is
created.
As part of this change, I've removed knowledge of the GPU delegate from
PlatformView. Now, all the calls from PlatformView to the GPU system bounce
through the UI delegate, which serializes the commands with other commands from
the UI engine to the GPU rasterizer.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/974483004
This is not complete gesture support by far, but it's a start.
MojoShell and Chrome use a C++ GestureDetector, this code attempts
to use the Android (Java) GestureDetector instead.
We probably should not be sending gesturetap until we've decided
it's not a scroll, etc, but this implementation does not go that far.
I had to fix a bug whereby we were assuming the InputEvent.time_stamp
was in TimeDelta's internal format, which was wrong. When we get
time_stamp from Android its in ms since boot.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/969493002
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 plumbs resize notifications from SkyView to Engine. I've taken the
opportunity to reorganize how notifications generated by SkyView are plumbed to
the GPU and UI threads. This approach should reduce the amount of plumbing
needed for new notifications.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/880443003
This CL causes sky/shell to create a blink::WebView to show that sky/shell
links with sky/engine. In the process, I've made it easier to be a trivial
embedder of sky/engine by removing the requirement to implement
blink::ServiceProvider.
This CL also causes sky/shell to link with mojo/edk/system to resolve link
errors with Mojo fabric (e.g., MojoClose, MojoWriteMessage, etc). To make this
work properly, we'll need to initialize the EDK in a future CL.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/873923003
