- New chromium clang rules require explicit external destructors so
system/lib added for MessagePipe, DataPipe and SharedBuffer
- New chromium clang rules require override and no virtual in
declarations, so many files updated.
- cc_strip_video patch updated.
BUG=
R=jamesr@chromium.org
Review URL: https://codereview.chromium.org/988693005
This switches to using StrongBinding<>s in sky's ContentHandlerImpl
and TestHarnessImpl implementations.
These are the last uses of the deprecated InterfaceImpl<> helper in
the mojo repo (more uses exist in other repos).
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/934403002
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
1. If notifyTestComplete is called before the first paint,
give a clear assert instead of a confusing crash.
2. Add runAfterDisplay. This is a copy of the equivalent
file in Blink. Avoids the incorrect 100ms setTimeout. I had
thought there was a deeper bug here, but it appears to just
be the issue from #1 now that we properly pump frames
in testing mode by using a face Surfaces application.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/826343003
-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/interfaces/input_events
to this:
//mojo/services/input_events/public/interfaces
This CL also makes the Mojo-side changes necessary to roll this change into
Chromium.
TBR=beng
Review URL: https://codereview.chromium.org/788353002
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
Since we don't support using the component build to produce mojo apps,
we can simplify the build targets in a few ways:
*) every mojo_native_application must depend on the c system thunks,
so just make that part of the template instead of requiring the dep
*) there's no such thing as depending on gles2 headers from a component,
so delete the forwarding group.
Most targets that want to use the gles2 headers in a mojo context
want to depend on an implementation through the thunks, so
//mojo/public/c/gles2 does just that. A smaller number of targets (such
as the implementation of the thunks) want to just depend on the headers
but not an impl, so they can depend on //mojo/public/c/gles2:headers.
The //mojo/public/gles target isn't that useful since the only thing we
expose is a set of C entry points.
We can probably also simplify the c system targets, but that's trickier
due to more extensive use from the chromium side.
BUG=438701
R=viettrungluu@chromium.org
Review URL: https://codereview.chromium.org/780733002
This script isn't quite working, but it's valuable to checkpoint the work at
this point. I'm coordinating with the chromeperf.appspot.com folks to get the
server to accept the data.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/702603005
