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
This is a proof of concept for replacing ui/views
code with Sky instead. erg says this will allow him
to delete 10s of thousands of LOC from mojo.
Mojo does not yet expose the current binary's URL:
https://docs.google.com/a/chromium.org/document/d/1AQ2y6ekzvbdaMF5WrUQmneyXJnke-MnYYL4Gz1AKDos
So I've worked around that by passing the url
of the binary via the helper script.
I discovered several bugs in the wm_flow code
including that it doesn't handle view resizes
(during embiggen). Related, I discovered that
every time a new window is made it drops the
connections to the embedded.cc app from the
previous window, since the ViewManagerDelegate
is incorrectly implemented as part of the
ApplicationDelegate on both app.cc and embedded.cc.
We'd need to split out a separate per-view object
in both of those apps to handle the
ViewManagerDelegate calls.
There are some changes to logging during loading
as well as the CopyToFile helper to have better
error reporting. I hit several issues early on trying
to get mojo to load the http: urls correctly, including
eventually running out of disk space on my /tmp
and mojo then silently failing to launch the app
(due to mojo never clearing its caches crbug.com/446302).
I had to re-write the mojo_demo.sh script in python
as well as split the sky_server handling code out of
skydb into a separate python module in order to cleanly
launch sky_server. We could use a separate server
if we wanted to but the primary benefit of sky_server
is that it sets up the proper url->disk mappings into
the generated file directories, etc.
BUG=443439
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/817573003
This adds two benchmarks, one for flights-app which doesn't use data binding
and one for city-list which uses lots of it.
1st runs in each benchmark contain the cost of collecting all the metadata
about bindings and templates in addition to creating instances. Later runs
only contain the cost of creating instances.
Overall it looks like SkyBinder is 24.4% - 35.5% faster depending on if
you're using data binding (the performance improvement is larger if you are).
It also appears to put less pressure on the GC.
== flights-app.sky benchmark ==
TemplateBinding:
flights-app.sky => [103.0, 27.0, 26.0, 26.0, 27.0, 26.0, 39.0, 29.0, 29.0, 72.0]
flights-app.sky => [101.0, 27.0, 27.0, 27.0, 27.0, 26.0, 37.0, 33.0, 26.0, 69.0]
flights-app.sky => [103.0, 27.0, 26.0, 26.0, 27.0, 26.0, 37.0, 27.0, 28.0, 71.0]
1st run avg = 102.33333333333333
avg = 33.148148148148145
SkyBinder:
flights-app.sky => [78.0, 25.0, 25.0, 25.0, 25.0, 30.0, 34.0, 26.0, 25.0, 32.0]
flights-app.sky => [77.0, 28.0, 25.0, 26.0, 26.0, 28.0, 31.0, 23.0, 26.0, 26.0]
flights-app.sky => [77.0, 25.0, 25.0, 24.0, 25.0, 28.0, 31.0, 23.0, 25.0, 24.0]
1st run avg = 77.33333333333333
avg = 26.51851851851852
24.4% reduction for 1st run, 20% reduction for normal runs. Normal runs
actually seem maybe only 5% faster, but it looks like pre SkyBinder there
were occasional runs that took 250% longer than normal from GC pauses. If I
increase the iteration count for SkyBinder I can see those long pauses
again, but they're much less frequent presumably because SkyBinder creates
less garbage.
== city-list.sky benchmark ==
TemplateBinding:
city-list.sky => [820.0, 609.0, 600.0, 529.0, 430.0, 437.0, 387.0, 462.0, 541.0, 415.0]
city-list.sky => [827.0, 599.0, 551.0, 481.0, 436.0, 425.0, 363.0, 366.0, 427.0, 364.0]
city-list.sky => [823.0, 574.0, 467.0, 483.0, 444.0, 429.0, 364.0, 363.0, 433.0, 367.0]
1st run avg = 823.3333333333334
avg = 457.25925925925924
SkyBinder:
city-list.sky => [521.0, 369.0, 320.0, 285.0, 319.0, 273.0, 267.0, 262.0, 272.0, 331.0]
city-list.sky => [553.0, 362.0, 314.0, 284.0, 327.0, 278.0, 263.0, 264.0, 249.0, 290.0]
city-list.sky => [556.0, 355.0, 317.0, 289.0, 333.0, 277.0, 269.0, 266.0, 264.0, 263.0]
1st run avg = 543.3333333333334
avg = 294.8888888888889
34% reduction for 1st run, 35.5% reduction for subsequent runs. This also
shows less variance in the later runs than pre SkyBinder which I think might
again be less GC pressure.
TBR=ojan@chromium.org
BUG=
Review URL: https://codereview.chromium.org/834983002
Includes changes for CommandLine moving into the base:: namespace, some
PickleIterator updates, and some animation API changes.
Review URL: https://codereview.chromium.org/817653003
The ownerScope property is equivalent to walking up the parentNode
pointers until you hit the top and returning that node if it's a
Document or ShadowRoot.
This means that the ownerScope of ShadowRoot and Document is always
itself, and the ownerScope of an Element that is not the descendant
of a ShadowRoot, and is not in the document is null.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/810793005
We were not setting the __proto__ property of the generated constructor
so the generated class didn't inherit from the passed class which meant
that statics were not available.
This patch adds the missing call to setPrototype (which sets __proto__).
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/814683002
The syntax for implementing a SkyElement is now:
<sky-element name="element-name">
<template>
<!-- template here -->
</template>
<script>
module.exports = class extends SkyElement {
attached() {
// ...
}
// .. methods here ..
}.register();
</script>
</sky-element>
The register() static method on SkyElement subclasses calls
document.registerElement() and returns the generated constructor.
It uses the parent <sky-element>'s name attribute to set the name
of the element.
R=rafaelw@chromium.org
Review URL: https://codereview.chromium.org/788943003
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
Also fixed all the XHR tests to actually run and work
I learned from elliot that the it function has to
take a "done" argument to be treated asynchronously.
My utf8 conversion is a hack, but we deleted
window.TextEncoder (it was a module) when we forked.
We could resurrect TextEncoder (and probably should)
but I've left that for a separate change.
I also augmented sky_server to have a special /echo_post
handler so we can test POST requests.
R=esprehn@chromium.org
BUG=
Committed: 5ef81d249b
Review URL: https://codereview.chromium.org/810523002
Also fixed all the XHR tests to actually run and work
I learned from elliot that the it function has to
take a "done" argument to be treated asynchronously.
My utf8 conversion is a hack, but we deleted
window.TextEncoder (it was a module) when we forked.
We could resurrect TextEncoder (and probably should)
but I've left that for a separate change.
I also augmented sky_server to have a special /echo_post
handler so we can test POST requests.
R=esprehn@chromium.org
BUG=
Review URL: https://codereview.chromium.org/810523002
-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/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
