This also fixes the C++ side to give the right baseline information.
Previously it was giving the baseline distance for the font, but not
for the actual laid-out text.
I considered also providing a "defaultBaseline" accessor that returns
the distance for the actual dominant baseline, but it turns out right
now we never decide the baseline is ideographic. We always use the
alphabetic baseline. We should probably fix that...
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1200233002.
Previously, the wavy underline code only knew how to draw a complete
period.
This change adds the ability to draw a partial period of the wave.
Previously, the code tried, but failed, for reasons I cannot
determine, to fit the width of the inline by extending the period to
be an integral factor of the width.
This is bad because as you type text, the underline wave of earlier
characters would jiggle.
This fixes that by not changing the period of the wave when the length changes.
It's interesting to compare this to the previous code. Here's a test
that shows this in Safari/Chrome:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3543
Notice how as you type "i"s, the underline changes how far it extends
(obviously a bug) but also what the period of the wave is (which looks
especially ugly when typing).
Firefox, on the other hand, renders something that isn't actually a
wave; it's a saw-tooth pattern with straight lines between each
direction change. This works for small font sizes at low densities,
but is not great on modern screens.
This CL addresses this issue by computing the bezier curve control
points for the curve that consists of just the remaining fraction of
the period. To do this, however, it allocates an object and solves a
bezier for x (which includes a numerical integration), which is
certainly a performance concern. Apps that try to wavy-underline an
entire UI are going to maybe suffer. Since this is typically going to
be used for spelling checkers, it means people who spell better will
have better performance.
(I haven't tested this to see what the perf impact actually is. If
it's actually bad, we can probably cache the results of the
integration pretty trivially.)
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1189403005.
I had to add back document.createText() since new Text()
does not work in the new world yet.
LayoutRoot is a new Dart-exposed class which holds the Frame and
all associated machinery, sufficient to trigger a restyle
and layout of the subtree.
This is all kinda hacky and I'm sure likely to cause many
crashes if folks call random methods on these disconnected
trees.
But this makes it at least possible to paint text for now
and we can improve this in the coming days.
This really should have Adam's review. It's hugely hacky
but I'd like to negotiate out with him the timeline on
which we should fix some of these hacks.
R=ianh@google.comTBR=abarth@chromium.org
Review URL: https://codereview.chromium.org/1148253003
This adds a new abstract 'Canvas' which is similar to SkCanvas.
PaintContext implements Canvas while still having its
own commit() method to cause the paint actions to apply to
the Element for the next frame.
This adds a new PictureRecorder which also implements Canvas
and has an endRecording() method which returns a Picture
(another new interface) which can be held from Dart.
There is also now a rootPicture setter on Document which takes
a Picture and will then make the Document draw that Picture
until changed.
This piggybacks on the existing custom painting system
which adds the painting at background-and-borders paint
time so technically if you both set rootPicture as well as
construct a DOM you will draw the DOM on top of your picture. :)
R=mpcomplete@chromium.org
Review URL: https://codereview.chromium.org/1122423009
This exposes the last hooks needed to implement flexbox layout. For now,
I didn't worry too much about the exact API we're exposing since this will
all change with the upcoming redesign (e.g. https://codereview.chromium.org/1093633002).
minContentWidth == the width if the element were to wrap at every wrapping point (not including border/padding)
maxContentWidth == the width if the element were to only wrap at hard wrapping points (e.g. \n inside a whitespace: pre).
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1101793003
Text can only only inside paragraphs and inlines. This patch makes it
so we stop putting such text nodes in the render tree at all if their
parent is not a paragraph or an inline.
This is the final step in making it so that we don't create anonymous
renderers, which fixes a crash in the new custom layout code.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1077473002
With this gone, cursors will no longer change
on hover when running Sky on a desktop.
Then again the iGeneration doesn't
probably even know what a mouse is, let alone
have a burning desire to set a CSS3 custom-cursor.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/1076623002
We only ever create RenderParagraphs now. The only non-trivial change here
is making RenderView a RenderFlexibleBox. This required changing custom.sky.
That test was written in a fragile way that behaved differently if we
did multiple layouts. Instead, having it be less racy and only change
values during the test itself.
This also throws a wrench in moving all the layout code to dart
because we can't set the layout manager on the RenderView. Maybe
we need to explicitly let you do so.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1068683002
-Make display:flex, flex-direction: column, flex-shrink: 1 the default.
-Simplify StyleAdjuster::adjustStyleForAlignment to remove special cases we
won't need as we make flex the default and remove absolute positioning.
-Fix a bug this exposed in column flexboxes where we'd apply the wrong edge
of border/padding/margin.
-For now leave the default of align-items:stretch. The main change here is
that iframe/img will do width:auto the same as blocks (i.e. the width of
the parent). I think this is a good change, but we'll have to see how it feels
in practice.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1061163002
-Temporarily add setting override width as well so that we correctly bypass in RenderBox::computeLogicalWidth.
-Add setNeedsLayout so that the author code can force layouts (e.g. when the container's width changes).
-Have setLayoutManager force a reattach of the element if it's renderer wasn't a custom layout one before.
-Remove the laying out of children from RenderCustomLayout::layout. This is the job of the author code.
-Add a test case.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1055263002
This allows setting x/y/width/height directly on an element
during a synchronous layout callback. At the moment, you can do
dangerous things (e.g. change tree structure). In a followup patch
we'll make that impossible via an IDL guard.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/1023753007
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
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
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
