This CL adds license blocks and cleans up a number of Dart idioms in fn.
Specifically, I've marked several fields as |final| and used Map#putIfAbsent in
some appropriate places.
R=rafaelw@chromium.org
Review URL: https://codereview.chromium.org/973613004
If there is jank, we might not get a frame time that's just after the last
frame, which means we'll stop generating animation frames before hitting 1.0
exactly.
In this CL, we introduce state to takeWhile to cancel the stream after emitting the
1.0.
R=rafaelw@chromium.org
Review URL: https://codereview.chromium.org/975153002
This is basically skydb v2, except only for android.
I revisited some of the architecture decisions I made
in writing skydb. I also separated skyserver.py from
dependency on skypy/paths.py since it wasn't really adding
any value.
We could make this way fancier, but this should at least
make working with SkyDemo.apk easier for now.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/960233007
This is just a proof of concept. If we like this direction, it will move out of the examples directory (likely re-written) and be committed in smaller pieces with unit tests and formal reviews.
TBR=abarth
BUG=
Review URL: https://codereview.chromium.org/971183002
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
-Remove AbsoluteClipRects. It's never used.
-Inline some static functions. In the process,
noticed that the clip rects for CSS clip are broken.
In theory, this patch fixes that, but I didn't test it
since we probably want to just remove the feature anyways.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/964723004
This patch makes it so that querystrings are no longer considered part of a mojo application's identity.
So if you connect to http://a?foo, then http://a?bar, you'll end up talking to the same application, just two different connections.
The URL of each connection is sent to the app via a new param in AcceptConnection().
This patch also adds some app tests that exercise http app loading, which wasn't tested before.
R=qsr@chromium.org
Review URL: https://codereview.chromium.org/943053003
This CL attempts to fix clean builds by adding a missing dependency from
service_registry to service_provider.
Also, I've attempted to fix the sky tests by updating the reference to
service_registry.mojom.dart.
TBR=hansmuller@chromium.org
Review URL: https://codereview.chromium.org/968553002
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
It doesn't do anything RenderLayer specific anymore. This
does mean adding another pointer to RenderBox. We might want
to do something about that eventually, but for now it seems fine
to make forward progress in terms of getting rid of the RenderLayer
tree.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/963253002
ServiceRegistry enables a chain of Mojo applications to accumulate
services without wrapping and forwarding the incoming ServiceProvider
request.
Sky's DocumentView adds ViewManagerClient to the ServiceRegistry (if any)
that's provided to it via ConnectToApplication(). Sky applications can add
additional services with embedder.serviceRegistry.addServices().
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/958673002
-Remove RenderLayerFilterInfo. It was just a static map for
FilterEffectRenderers. Instead, put the FilterEffectRenderer
directly on RenderLayer.
-Make FilterEffectRenderer not be RefCounted. This involved
deleting a ton of dead code around ReferenceFilters since they
were the other subclass of Filter. As best I can tell,
reference filters are already don't parse in Sky, so this should
just be removing dead code.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/962543003
This change causes the generated abstract class having the same name as the interface to contain only the interface's method declarations. The generated Proxy class then implements the base class. In addition to implementing the interface methods, the generated Proxy class has one private field _proxyImpl, which is a MojoEventStreamListener and manages sending messages and receiving responses. Operations on the ProxyImpl (close, bind, etc.) are exposed through generated utility functions.
The generated Stub is largely as before with the difference that a class providing a service will implement the mojo interface and *have* a Stub rather than be a Stub. Where appropriate, this change also calls listen() immediately where a Stub is constructed.
BUG=
R=hansmuller@google.com, sky@chromium.org
Review URL: https://codereview.chromium.org/959993002
-Move perspectiveOrigin to RenderBox. It's only used in
one place and called on a RenderBox.
-Inline some methods that were just calling out to the renderer.
-Inline updateStackingNode() into the constructor and remove
the branch since requiresStackingNode is always true.
-Delete a bunch of dead code.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/961053002
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
