Sky doesn't really have many built in elements, we no longer support
<foo is="my-element">. This does mean you can't extend <import>,
<script> or <style>, but we'll figure that out later.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/831993005
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
Specs: Make the StyleValueResolverSettings have a safer API for use in
chains of StyleValues.
Other sundry minor changes.
Review URL: https://codereview.chromium.org/836193002
Now you can use the attributes attribute on <sky-element> that
accepts a set of name:type comma separated pairs to control
the reflected attributes. ex. attributes="size:number"
Each attribute creates a getter and a setter on the element that returns
the correct type and will coerce the string attribute values into the
right type. It also correctly hooks into the data binding system.
A new callback is added: {name}Changed(oldValue, newValue) which will
be invoked whenever the attribute with that name changes and gets the
correctly coerced type values. See the <sky-radio> or <sky-checkbox>
widgets for examples of using the new callback.
Number attributes default to 0, booleans to false, and strings to empty
string. There is no way provided to set a different default, for that you
can use hasAttribute in the created callback to conditionally set a value.
Don't just assign the property there otherwise you'll overwrite the value
from the parser.
Another behavior change from making this work is that now attributeChanged()
is called for each attribute, even when the element is created by the
parser.
Overall this allows a nice simplification to the <sky-button>,
<sky-radio> and <sky-checkbox> widgets.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/836923002
Node since it is used by text nodes and document nodes as well.
Specs: Make it possible for an element to set what layout manager
class it uses.
Specs: Expose the root layout manager as mutable state.
Specs: Update the runloop to have more detail.
Specs: Add support for transitions, by making the resolver for a value
know when it has been called for the first time, and giving it access
to the previous cached value, and letting it store state on the render
node.
Other sundry changes.
Review URL: https://codereview.chromium.org/835973003
Warning: this change will require Chrome changes. See
https://codereview.chromium.org/803173009/#msg6.
Added ProxyBindings and StubBindings methods that expose
bindings-related properties for generated Proxy and Stub classes
without risking name collisions.
Outgoing "in/out" interface valued parameters are now specified as
functions that are applied to the out value.
Note: the leading capital in the Proxy,StubBindings() methods is
unconventional. It seemed OK given their unusual role: they can be
viewed as transformers from "Foo" objects to "FooBindings" objects.
BUG=
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/803173009
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
SkyBinder is a rewrite of TemplateBinding.sky that uses classes and weak maps
and doesn't add expandos to any of the DOM objects.
It has a few differences from TemplateBinding.sky:
- null doesn't create instances in repeats.
- One time bindings are removed ([[ expr ]]), we'll add them back later.
- The bind attribute is removed.
The system is also less generic and is specialized to be used when
creating SkyElement instances.
The commit history that created SkyBinder can be found at:
https://github.com/esprehn/sky-binder/commits/masterTBR=ojan@chromium.org
Review URL: https://codereview.chromium.org/821353003
Includes changes for CommandLine moving into the base:: namespace, some
PickleIterator updates, and some animation API changes.
Review URL: https://codereview.chromium.org/817653003
Now inside the <template> of a SkyElement you can use
on-eventName="method" on any element to add event listeners.
For example you can write <sky-button on-click="handleClick">
and then define handleClick(event) on the element class that
contains the button.
In adding this and tests I also realized that property bindings
were not setup on the initial call to bind(), which is now
fixed in this patch (See change to Node.prototype.bind).
R=eseidel@google.com, rafaelw@chromium.org
Review URL: https://codereview.chromium.org/812713005
Eventually we'll want to replace these with something
fancier like polymer, but this exercise helped us
find several bugs in the engine as well as
removed one more blocker from using Sky to
replace mojo/views usage in mojo/examples.
R=esprehn@chromium.org
BUG=443439
Review URL: https://codereview.chromium.org/809233002
The StyleEngine only lives as long as the document is attached,
and the document is always detached before it is destroyed. This also
means the document for the style engine always has a frame, so we
don't need to conditionally create the CSSFontSelector.
R=eseidel@google.com
Review URL: https://codereview.chromium.org/786933008
StyleSheetCollection is tied to TreeScope in lifetime, and should
really just be a member of it like the ScopedStyleResolver. Doing
this makes the StyleEngine simpler and removes the error prone
manual clean up.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/815653002
insertedInto and removedFrom should always be paired, there's no
reason to track this state separately when updating the childShadowRoot
bits.
I also removed the inDocument() checks from ShadowRoot::insertedInto
and removed from since distribution happens in detached subtrees too.
It appears that while they were wrong, it didn't matter because the
state was only used together with containsContentElements() in a check
of the form:
if (!containsShadowRoots() && !containsContentElements())
return;
which meant that while the containsShadowRoots bit might be wrong false
incorrectly, the containsContentElements is always correct so we'd
never take the early out incorrectly.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/801643009
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
- for layout manager to animate things,
- for elements to continue to live in the render tree after they've left the DOM,
- to define custom units like 'em' for 'vh',
- to define custom properties like 'font-size'...
(Examples haven't yet been updated.)
Review URL: https://codereview.chromium.org/810173002
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
The clients were only used to call clearResolver(), but all clients in Sky
are from the same document, so we can just store the document instead. We
can also use the lifetime of the StyleSheetContents object to manage the
cache in the StyleEngine instead of the list of clients.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/791633010
Just walk the DOM instead. This will be slower, but I'm going to get rid
of the global RuleFeatureSet anyway, so this is just a temporary measure
to simplify the system. Removing the set also means removing a bunch of
special cases for when the document didn't have any ShadowRoots with
styles (which is very unlikely in Sky).
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/810893002
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
Sky doesn't have tree boundary crossing rules so we don't need to sort
the list of tree scopes in the StyleEngine. This was needed to make
tree boundary crossing rules apply in the right order.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/807933003
In Sky <style> elements in import documents don't apply to the main document,
so we don't need the StyleEngine to be aware of the import tree. This change
makes us only create the StyleEngine for active documents.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/813493003
