The bindings, core, and application libraries are now referred to as, e.g.:
package:mojo/public/dart/core.dart
Since the handle watcher remains in the snapshot, it no
longer refers to types defined in core.dart. References to types defined
in core.dart are also removed from mojo_natives.cc.
In Dart packaged apps, the SDK is zipped up under mojo/public/dart.
For embedder tests, the SDK is copied into the generated source output directory.
A base_dir parameter is added to the 'dart_package' and 'mojom' GN macros so that
consumers of the Mojo SDK can all import using the same URIs regardless of where
the SDK lives in their source trees.
BUG=
R=erg@chromium.org
Review URL: https://codereview.chromium.org/1027603002
StockMenu was creating a container for the sole purpose of applying style to
PopupMenu. Now we just use a StyleNode.
Also, I've reverted the change to make box-sizing default to border-box. It
turns out that CL wasn't effective because we didn't use the initialBoxSizing
function to initialize box sizing. I've made us use initialBoxSizing but switch
the default back to content-box because actually using border-box breaks a
bunch of stuff.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1024083003
Instead of running paint requests during microtasks, we run them after updating
layout for the current frame. After draining all the paint requests, we then
drain whatever commits are available.
It's still possible that requestPaint callbacks can dirty style and layout
information, so we need to clean that information after servicing the requests.
Ideally we'd block these callbacks from dirtying style or layout information.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/1027563002
This CL adds just enough custom painting to Sky to make
sky/examples/painting/circle.sky draw a circle. Over time, we should be able to
elaborate this system into something interesting and to make it actually work
in a reasonable way.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/1017593005
1) Factors InkWell out of Material so that components can use an ink well
without needing the shadow/level machinery.
2) Makes the ink effect move at a different velocity once the tap has actually
occurred, converging with the spec. We don't have the right speeds yet, but
at least we're approaching the right shape.
3) To support (2), added a primaryPointer attribute to GestureEvents to let
authors coorelate gesturetapdown events with later gesturetap events.
4) To support (2), modernized SplashAnimation to used AnimatedValue and friends.
5) Added more constants to view-configuration.dart that match Android.
I've also removed the cancelling of the ink effect on scroll. The proper way to
do that is to notice that someone in the event chain is listening for
scrollstart and delay the beginning of the ink effect for some period of time.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1019023003
This CL is a first step towards custom paint. It introduces a class that can
draw a circle into an SkPicture. Future CLs will wire the SkPicture into the
render tree and expose this object to script.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/1017373003
Dart actually expects package: to work. This CL makes package:foo
map to /packages/foo, similar to how Dartium or bin/dart would expect.
This also means overlaying the /gen directory over the actual package
outputs (as consumers of an SDK would expect) as well as adding
an additional /lib indirection for the actual package source as
the Dart pub tool will expect.
This is far from perfect, but it unlocks us actually producing a
sky SDK.
I expect there may be some fallout from this change as I'm sure I
missed some package: uses. We also don't have a general solution
for all /foo/bar/baz includes which randomly included parts
of mojo's source directory. Those will need to be updated to use
a package: and deploy_sdk.py taught how to build a package for them.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/990493002
hit-testing needs to walk in backwards order from paint.
The previous attempt at reverse sorting by z-index didn't
reverse things with the same z-index. Instead, forward
sort the same way as we do with paint and then reverse
the whole vector.
R=abarth@chromium.org, eseidel@chromium.org
Review URL: https://codereview.chromium.org/986793002
-Remove AbsoluteClipRects. It's never used.
-Inline some static functions. In the process,
noticed that the clip rects for CSS clip are broken.
In theory, this patch fixes that, but I didn't test it
since we probably want to just remove the feature anyways.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/964723004
It doesn't do anything RenderLayer specific anymore. This
does mean adding another pointer to RenderBox. We might want
to do something about that eventually, but for now it seems fine
to make forward progress in terms of getting rid of the RenderLayer
tree.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/963253002
-Remove RenderLayerFilterInfo. It was just a static map for
FilterEffectRenderers. Instead, put the FilterEffectRenderer
directly on RenderLayer.
-Make FilterEffectRenderer not be RefCounted. This involved
deleting a ton of dead code around ReferenceFilters since they
were the other subclass of Filter. As best I can tell,
reference filters are already don't parse in Sky, so this should
just be removing dead code.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/962543003
-Move perspectiveOrigin to RenderBox. It's only used in
one place and called on a RenderBox.
-Inline some methods that were just calling out to the renderer.
-Inline updateStackingNode() into the constructor and remove
the branch since requiresStackingNode is always true.
-Delete a bunch of dead code.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/961053002
However WebView::close() no longer crashes. close() is never called
in MojoShell since mojo can't shutdown yet.
I tried closing the existing WebView and replacing it
but somehow that caused it to only draw red. After a while
of looking at this with abarth we decided to just load into
the same WebView for now.
Eventually we should do something smarter where we start the
provisional load and only replace the webview once the new one is
ready, but that's a later CL.
R=abarth@chromium.org
BUG=
Review URL: https://codereview.chromium.org/952273003
-Consolidate the beginTransparencyLayers calls. The call
on layer()->parent() was just not needed as best I can tell
and the filter one could just be shared with the non-filter
codepath. FWIW, blink has already made a similar set of changes.
-Don't walk up the tree calling beginTransparencyLayer.
We're doing this in a recursive call down, so we've already
created the transparency layer for any transparent ancestors.
-Remove unused TransparencyClipBoxMode argument.
-Inline the paintingExtent method.
-Removed unused REVEAL_TRANSPARENCY_LAYERS #define.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/959543002
-Get rid of paintsWithTransform.
-Remove currentTransform. It was only ever called with
IncludeTransformOrigin and on non-null transforms.
-Remove renderableTransform. It was only called on
non-null transforms.
-Remove a layer()->parent() branch. The ASSERT had been
added in a previous patch, but the branch wasn't removed.
-Inline makeMatrixRenderable. It was only called in one
place.
-Add a test to make sure that transform origin is corrrectly
excluded from the transform computedStyle.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/958463002
This patch adds utility functions which provide a single choke point for calling into sky application code. For now this is only serving the purpose of having a common trace event for calls into app code.
R=abarth@chromium.org, abarth
BUG=
Review URL: https://codereview.chromium.org/941153003
Merge most of it into RenderBox. Only RenderBoxes can have
layers now. This also meant a bit of code could be cleaned up
since some virtuals (e.g. updateFromStyle) are no longer needed
since they're only called on RenderBoxes.
collectSelfPaintingLayers is the only bit that's moved into
RenderBoxModelObject instead of RenderBox. That's because we
need to be able to recurse down into RenderInlines since they
may contain RenderBoxes that have selfPaintingLayers.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/953673002
This removes support for opacity, filters and clip-path
on RenderInlines. If you want inline content that uses
these properties you need to use an inline-block. We
may want to add back support for opacity or filters
on inlines eventually, but we'd implement it differently
and right now they're getting in the way.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/950963003
This CL updates sky-box, sky-button, sky-checkbox, sky-input, and sky-radio to
work in Dart. We don't have a data binding system yet, so there's a bit more
plumbing in the code.
This CL adds support for sky-element@attributes, which lets you specify which
attributes your element supports. We use this information to synthesize getters
and setters for those attributes and to dispatch to mumbleChanged methods when
the attributes change.
I've also wrapped the widgets demo itself in a sky-scrollable so the whole
thing scrolls.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/946813005
After this CL, you can use <sky-element> to describe custom elements. The
current iteration is very basic and is hardcoded to "example", but its a start.
This CL renames the |init| function to |_init| to prevent importers from
calling it directly. Also, we now pass the <script> element to |_init| to give
some context.
R=ojan@chromium.org, eseidel@chromium.org
Review URL: https://codereview.chromium.org/950493003
On the web, if you set position:absolute, but not
top/right/bottom/left, then the absolute goes where it
would have gone if it wasn't positioned. The use-cases for
this are slim and it introduces a lot of complexity to the
engine.
Also changes behavior in the presence of direction:rtl.
On the web, direction:rtl and top/left:auto would
sometimes set right:0. Instead we always position at
0,0 if the opposing values are auto.
This removes the code for this positioning and allows
simplifying a bunch of dirty bit handling code since
we don't need to setNeedsLayout if lines move around
or wrap differently.
The test cases did change their output, but the new
positioning all looks correct to me.
Review URL: https://codereview.chromium.org/944073006
We only need to walk the immediate children of the paragraph.
The other inline children of the paragraph will get paint called
on them and they will then appropriately add the self painting
layers to the array inside their paint calls.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/945223002
-ASSERT(layer()->parent()) in all the transform codepaths since
the RenderView cannot have a transform.
-Early return if the content rect does not intersect the
damage rect in the painting code. We don't need to do
any of the filter and/or transparency dance if we're
not going to paint anything. This also allowed for
removing the shouldPaintContent bool.
-Remove a random style() null check that can't be hit.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/950553002
This CL implements custom elements. The design is as follows:
1) Authors subclass Element and call registerElement.
2) When we create C++ elements for custom elements, we call the author's
constructor synchronously.
3) The attach/detach/attributeChanged callbacks are called either:
a) when exiting the current custom element callback scoped (e.g., before
returning from appendChild), or
b) when draining the microtask queue.
The implementation in this CL is a bit fragile because we don't detect name
registration conflicts and we let you create custom elements with the same name
as built-in elements. Also, not every part of the engine is prepared to execute
script synchronously below createElement. We'll need to iron out these issues
over time, but this CL is a start.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/943013002
The only bit that was still used was the
containingBlockLogicalWidthChanged check in
RenderBlock::widthAvailableToChildrenHasChanged.
a4f1e657ff
is the patch that added that code. I added a
test to confirm we still pass the test case
that code was added for.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/945003002
