This CL goes from this:
//mojo/services/public/interfaces/navigation
to this:
//mojo/services/navigation/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/796783002
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 patch remove the Web Animations & CSS Animation runtime flags (and enables both). Removes prefixed Aninamations & Transitions and adds some basic tests & test support API.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/760183003
This CL goes from this:
//mojo/services/public/cpp/geometry
//mojo/services/public/interfaces/geometry
to this:
//mojo/services/geometry/public/cpp
//mojo/services/geometry/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/790213002
This CL goes from this:
//mojo/services/public/cpp/network
//mojo/services/public/interfaces/network
to this:
//mojo/services/network/public/cpp
//mojo/services/network/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/789243002
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
Sky can't really build on its own. We were previously
using the 'sky' build target for this but it didn't
fully anticipate all of our dependencies. The most
recent break was when James removed /mojo/shell
from mojo.
Instead of sky listing out each and every service
which it depends on, we should just get used to
building root like other mojo developers.
Thankfully there is already a helpful tool
for this called mojob.py. I've updated our
readme to reflect this, and removed the mojo
dependency on the sky build group.
The purpose of the sky build group is to expose
all of the sky build targets up to the root level
BUILD.gn (which only depends on /sky), not to
be an independently buildable target.
R=jamesr@chromium.org, jamesr
BUG=
Review URL: https://codereview.chromium.org/764023007
We keep seeing timeouts on the bots that seem to be due
to cherrypy dropping requests on the floor, which in turn
causes imports to stall, which causes the test to time out.
In local testing, I was able to reproduce the timeouts
and wasn't able to do so with the go-based server.
R=abarth@chromium.org, eseidel@chromium.org
Review URL: https://codereview.chromium.org/746373002
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 adds a tracing service that can aggregate tracing data from
multiple sources and write a json file out to disk that trace-viewer can
understand. This also teaches the shell, sky_viewer, and various other
services how to register themselves with the tracing service and provide
tracing data on demand. Finally, this teaches the skydb prompt to tell
the tracing service to start/stop tracing when the 'trace' command is
issued.
The tracing service exposes two APIs, a collector interface and a
coordinator interface. The collector interface allows different entities
to register themselves as being capable of producing tracing data. The
coordinator interface allows asking the service to collect data from
all registered sources and flushing the collected data to disk.
The service keeps track of all open connections to registered sources
and broadcasts a request for data whenever the coordinator's Start
method is called, then aggregates all data send back into a single
trace file. In this patch, the tracing service simply gives all sources
1 second to return data then flushes to disk. Ideally it would keep
track of how many requests it sent out and give each source a certain
amount of time to respond but this is simple and works for most cases.
The tracing service can talk to any source that is capable of producing
data that the trace-viewer can handle, which is a broad set, but in
practice many programs will want to use //base/debug's tracing to
produce trace data. This adds code at //mojo/common:tracing_impl that
registers a collector hooked up to //base/debug's tracing system. This
can be dropped in to the mojo::ApplicationDelegate::Initialize()
implementation for most services and applications to easily enable
base tracing. Programs that don't use //base, or that want to register
additional data sources that can talk to trace viewer (perhaps providing
data that's more easily available from another thread, say) may want
to create additional connections to the tracing service.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/769963004
e223e0c6d51f027196a2597b556641328a65d4b5 accidentally
sent all elements down the margin:auto codepath.
The patch incorrectly removed just the
"&& containingBlockStyle->textAlign() == WEBKIT_CENTER"
instead of the whole clause.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/760143002
This moves the tracing code and mojoms from sky/viewer/services/ to
mojo/common/ in anticipation of refactoring these to be more widely
usable. This doesn't actually change behaviors yet.
BUG=436639
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/751303003
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
This regressed in 3db9471ae80bd492f2a346113d2323ba8eee0c09.
Accidentally sent some code down the override by sending the
top LayoutUnit instead of the left/right LayoutUnit. The
root problem was bad overloading, which is also fixed in
this patch. Inlined the overloaded method since one of
the calls was only called from one place.
The new test demonstrates the ellipsizing, but that doesn't
show through in the render tree dump. We don't get real
test coverage here until we either start doing pixel tests
or start exposing ellipsis in the render tree dumps.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/751483002
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
actually telling your child to paint, you just say where it would
paint. The platform then takes care of making sure all the dirty nodes
have their paint() methods called.
Review URL: https://codereview.chromium.org/744843003
Previously, skydb could be used only for Debug builds. As part of working on
graphics performance, I'd like to use it for release builds as well. This CL
teaches it to use the same configuration arguments as sky_server, test_sky, and
test_perf.
The downside of this CL is that you'll need to supply --debug in the common
case of working with a debug build.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/746473003
