mojo.Surface's client had two methods:
*) SetIdNamespace replaced by mojo.Surface.GetIdNamespace which returns
the id namespace via a callback.
*) ReturnResources split into a ResourceReturner interface which can be
(optionally) set on the mojo.Surface via
mojo.Surface.SetResourceReturner
Also beefed up the comments a bit.
BUG=451319
R=sky@chromium.org
Review URL: https://codereview.chromium.org/871373015
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
Surfaces identifiers have a local and a namespace component. The
namespace is particular to a connection. The local component is up to
the endpoint of the connection to manage. In contexts where a surface
that may be from anywhere is referenced, a fully qualified ID with both
the local and namespace component is needed in order to be unambiguous.
In contexts that can only apply to local surfaces only the local id is
needed.
This updates the mojo.Surface APIs that can only refer to local IDs to
only take the local component. In particular creating, destroying, or
submitting a frame can only refer to surfaces created on that connection.
References to surfaces within a frame may refer to local or foreign
surfaces so they use fully qualified IDs.
This also skips the SurfacesService indirection since many applications
can perform useful operations on a mojo.Surface interface such as create
surfaces and submit frames without knowing their ID namespace. The
namespace component is needed only to pass fully qualified IDs to other
actors that may wish to reference the produced frame.
R=sky@chromium.org
Review URL: https://codereview.chromium.org/826423008
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
Previously, there was no way for clients of the surfaces service to
appropriately rate-limit their frame submissions. We tried using the "return
resources" signal to rate-limit, but that's really a measure of how quickly
you're submitting new resources rather than how quickly the system is putting
up frames.
Currently, only the Sky compositor listens to this signal. Using this signal,
we're able to run sky/examples/spinning-square.sky in sync with the surfaces
service (that is, submitting exactly one frames every 17ms).
R=jamesr@chromium.org
Review URL: https://codereview.chromium.org/756673004
This CL fixes two bugs:
1) We need to enter the Ganesh context in order to destroy the GrContext.
2) We had a race condition whereby we'd try to upload a frame to a surface that
didn't yet exist. This CL fixes that race by adding a state to LayerHost to
wait for the surface to be created before trying to upload to it.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/753643002
