We're currently in a transition between using main.sky and main.dart
files as our main() entry point for Sky applications.
This CL makes this runtime controlable by path name. If it finds
a .dart in the path name it will use SkyView, otherwise it will
fall back to the existing WebView codepath.
SkyView does not expose a window object and much of the existing
Sky Engine is not initialized when main() is run. Clients should
be transitioning away from main.sky towards main.dart in the near
future, however main.dart is probably not ready for general
consumption at this point.
R=ianh@google.com
Review URL: https://codereview.chromium.org/1152313002
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
These now appear on internals as takeServicesProvidedToEmbedder and
takeServicesProvidedByEmbedder. When you call these functions, you get back the
raw int that represents the handle. We'll need to wrap them up inside the Dart
VM with the appropriate types. We can create a nice wrapper for that in a
future CL.
R=hansmuller@google.com, hansmuller@chromium.org
Review URL: https://codereview.chromium.org/944733002
Previously, the WebFrame need to be created with a data pipe consumer handle.
This CL makes it possible to create a WebFrame with a URL and have the engine
issue the network request.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/940703002
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
After this CL, we first convert from mojo::Event to blink::WebInputEvent before
feeding the event to the gesture recognizer. That means we process touch and
mouse events in the same way (because they are both represented as pointer
events). As a result, we now recognize scroll and fling gestures from mice.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/888773002
In order to have a high-quality gesture system, we need to know many details
about the fine-grained structure of applications. For example, different parts
of the view might be interested in recognizing different gestures and when you
recognize a certain gesture depends on the set of possible gestures.
This CL is a first step towards implementing
https://github.com/domokit/mojo/blob/master/sky/specs/gestures.md by moving the
gesture recognition into Sky where finer-grained information will be available.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/868463010
This fixes the race which is seen where mojo_shell will sometimes
launch with the wrong viewport metrics since the DisplayManager
will happily respond to GetViewportMetrics with default values
before the NativeViewport has fully booted and told it what the
actual values are.
I considered making DisplayManager hang until the NativeViewport
was ready, but I decided that it does make sense for the
ViewportMetrics (device pixel ratio, mostly) to change for a
view if it were to move between displays (as exists on desktop
OSes today).
R=abarth@chromium.org, sky@chromium.org
Review URL: https://codereview.chromium.org/880743002
It causes a full screen raster right now, lets name it for what it does.
This also matches the name used in PageAnimator.
Merge WebWidgetClient into WebViewClient.
They're always the same thing in sky. I also removed all the methods that
don't do anything in sky.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/880713003
There were two problems (both fixed in this CL):
1) When we were resized by the view manager, we forgot to deflate by the
device-pixel-ratio when converting to engine types. That caused use to
allocate a backing texture that was 9x what we needed.
2) When the surfaces system returned textures to us for re-use, we'd put them
into the cache even if they were the old size. That caused us to thrash the
texture cache. In this CL, we make the size of the textures in the cache
explicit.
R=eseidel@chromium.org
BUG=449001
Review URL: https://codereview.chromium.org/868263002
This removes the symmetrical nature of ServiceProvider and consistently
passes and uses a ServiceProvider + ServiceProvider& pair in places that
wish to bidirectionally expose services, such as the view manager.
The
view manager library now deals with InterfaceRequest<ServiceProvider>
and ServiceProviderPtr objects (i.e. c++ wrappers for handles) instead
of a concrete implementation of ServiceProvider to make it easier for
callers.
A number of places that were assuming a particular
ServiceProvider would always exist are updated to reflect the nullability
of the parameters in mojom and places that do not wish to ever look up
or provide services now pass nullptr instead of doomed pipe handles.
The JS application startup classes are reworked a bit to accomodate
exposing services on the third ConnectToApplication/AcceptConnection
parameter.
BUG=449432
R=abarth@chromium.org, sky@chromium.org
Review URL: https://codereview.chromium.org/858103002
This CL prepares us to expose the imported and exported service providers to
JavaScript. We can't quite do that yet becaues the API on mojo::View isn't
ready for us. However, we can get started by moving the call to Embed into
HTMLIFrameElement.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/793393003
This CL teaches the Sky compositor to record an SkPicture instead of just
drawing in immediate mode. Using an SkPicture will let us experiment with
various optimizations in Skia that preprocess the SkPicture before translating
the Skia commands to GL commands.
This CL also refactors the "display delegate" system now that we can hand off
an SkPicture to a rasterization backend. The new design requires fewer
backpointers and removes the static display delegate factory.
R=eseidel@google.com
Review URL: https://codereview.chromium.org/854303002
Moving WebInputEvent into public/platform lets us refer to it directly in core, which will let us remove the PlatformFooEvent classes.
The final pipeline will be:
1) mojo::InputEvent (IPC type, device pixels)
2) blink::WebInputEvent (platform abstraction, logical pixels)
3) blink::Event (DOM type, logical pixels)
If mojo::InputEvent used logical pixels, it would probably be easier to just
use mojo::InputEvent as the platform abstraction, but instead we use the
mojo-to-blink conversion to translate between device and logical pixels, like
we do everywhere else in Sky.
R=eseidel@google.com, eseidel@chromium.org
Review URL: https://codereview.chromium.org/860593003
In preperation for removing the Client annotation from ServiceProvider
this passes a second parameter of type ServiceProvider in the shell and
application Connect calls. In this patch the type signatures are updated
but the second parameter is basically unused. The intention is that the
first parameter |services| will be used for the connecting application to
request services from the connected application (as it does currently)
and the second parameter |exported_services| be used for the connecting
application to provide services to the connected application. We have
very few services exported in the second direction today - I'll update
them to use the second parameter in a follow-up patch.
R=darin@chromium.org
Review URL: https://codereview.chromium.org/845593003
Mojo events are in physical pixels but Sky works in logical pixels. This CL
changes the code that converts from Mojo events to Sky events to scale by the
device_pixel ratio.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/854603004
Surface IDs are composed of a namespace component and a local
identifier component. This splits up the two pieces in the mojom to make
it clearer.
This also simplifies the path for connecting to the surfaces service. In
order to perform any operations with surfaces, each client must know
what its id namespace value is. This was done by first connecting to a
SurfacesService interface and then calling CreateSurfaceConnection which
returned a Surface pointer and the namespace. Having to connect to this
extra interface and receive the Surface impl asynchronously complicated
startup code for applications by adding extra states in startup.
Instead of that, this allows connecting to the Surface interface
directly and promises that the ID namespace will be provided as the
first message in the pipe directed at the SurfaceClient. Callers can
then either block on startup or handle setting the ID namespace
asynchronously depending on what other things that thread could be doing
at the time.
In a follow-up, I plan to define the id namespace value 0 as meaning "the
namespace of this connection" which will allow creating surfaces and
submitting frames before learning the connection's namespace. The only
thing the namespace will be passing surface IDs to other clients for them
to embed.
This also removes the Size parameter from CreateSurface, which wasn't
used by anything. The size of submitted frames is part of the embedder /
embedee contract.
R=esprehn@chromium.org, sky@chromium.org
Review URL: https://codereview.chromium.org/807733002
-Add a --testing flag to sky_viewer and cause it to paint into an
SkBitmap instead of a ganesh surface so we can get the pixels out.
-Add GetPixelsForTesting to layer.cc to actually grab out the pixels.
-Add a reftest and a mismatch reftest. They need a setTimeout after
the load event. Unclear why or what the right fix is. Maybe we should
give internals some way to force the paint? If we don't have the
setTimeout, we paint a white page (so we do a paint, but with no
content).
-Add a DisplayDelegate to Layer so that Viewer can decide whether
to use the real ganesh backend or the SkBitmap one without littering
the whole code-base with is_testing bools and logic.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/797063002
This CL goes from this:
//mojo/services/public/cpp/surfaces
//mojo/services/public/interfaces/surfaces
to this:
//mojo/services/surfaces/public/cpp
//mojo/services/surfaces/public/interfaces
This CL also makes the Mojo-side changes required to roll this change into
Chromium.
TBR=beng
Review URL: https://codereview.chromium.org/792813002
This CL goes from this:
//mojo/services/public/cpp/view_manager
//mojo/services/public/interfaces/view_manager
to this:
//mojo/services/view_manager/public/cpp
//mojo/services/view_manager/public/interfaces
This CL also makes the Mojo-side changes required to roll this change into
Chromium (for both view_manager and window_manager, which was converted in an
earlier CL but for which these updates were not made):
- Updates rev_sdk.py to pull over the new directory
- Updates //mojo/services/public/mojo_services_public.gyp
TBR=beng
Review URL: https://codereview.chromium.org/790623003
These were a feature for allowing multiple
scripting contexts to access the same global
state without leaking wrappers between them.
For example, if the inspector wanted to
modify window.Array.dangerousFunction = ...
it wouldn't want the author's content to have
access to that.
This feature is not part of Sky's security model
and thus this is just dead code.
I tried to remove worlds all together, but there
is something special about how we use a
"fake" world (which is neither main nor isolated)
for GC, regexp and testing.
R=rafaelw@chromium.org, abarth@chromium.org
BUG=
Review URL: https://codereview.chromium.org/776143003
Turns out we need to reset the context before switching back to drawing with
Ganesh (i.e., call resetContext on the GrContext) to clean out whatever state we've
changed in the GL context. Now the city-list and the flights-app demos work.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/752653002
This CL updates ApplicationManager so that it always reconnect to an
application that is already launched.
To obtain this results, the following changes habe also been made:
1) The Loader interface has been simplified:
- The pipe to the shell if given during the Load request, so that loader do
not need to called RegisterLoadedApplication
2) PngViewer and PdfViewer allows multiple embedder to embed those.
3) For the second connection forward, Sky issue network request to get the
content of the page to display.
R=aa@chromium.org
Review URL: https://codereview.chromium.org/741453002
This starts to break the dependency between blink and
the new v8_inspector. At least now the front-end
object InspectorBackendMojo is treated as a peer to
WebView instead of WebView providing one.
Unfortunately I also had to teach Page about
InspectorHost in order to make it possible to
lookup the InspectorHost from the v8::Context.
I'm sure there is a nicer way to associate the
InspectorHost with the context but for now
I've chosen this path, we can untangle the
connection in a later patch.
I also ended up removing Page::allPages
and all callers, since they ended up as dead code.
R=abarth@chromium.org, yurys@chromium.org
BUG=435243
Review URL: https://codereview.chromium.org/746713002
The debugger can now correctly break on exceptions
and show the corresponding line in the inspector.
It correctly understands which scripts are internal
to sky and does not pause during them.
There is still a ton to make work here
(including stacktraces which I have not tested),
but basic functionality seems to work.
The current implementation is not smart enough to
unpause the inspector when the frontend disconnects.
BUG=434510,434513
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/727593004
