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 is the first step of getting rid of RenderLayer.
Instead of walking the RenderLayer tree, wall the RenderObject
tree and add any layers encountered to a vector to paint later.
This patch just consolidates and move the code from RenderLayer
to RenderBox and then changes the children painting to
iterate over the vector. Therefore we walk the RenderObject tree.
We still call out to RenderLayer in a bunch of places.
A followup patch will get rid of those.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/899753003
This is just a mechanical removal. No logic changes
beyond removing the PaintPhaseSelection checks.
Most of these are just early returns to avoid doing
unnecessary work if we're only painting selections.
But now that we paint selections during the foreground
paint phase, we no longer need the early returns since
we're going to paint everything anyways.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/886933002
These appear to have been for ensuring that you
only paint elements in a given subtree. It's not clear
to me exactly how you get to painting an element that
is not rooted at the RenderLayer you started with.
I think it's just not possible in Sky anymore.
This code was added in 2004 for drag images, which
we no longer support.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/882223005
Mostly just mechanical changes. The one surprising bit
is that RenderLayer no longer needs to explictly paint
outlines. I tested manually that before this patch,
the paintOutline call in RenderLayer was needed for
outlines on positioned elements and that after this
patch it's not.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/878023002
I believe this doesn't change behavior, but it's hard
to know since we don't have spellchecking hooked up.
Also, delete setToolTip. This is for tooltips on spelling
markers. We don't support tooltips.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/830273006
This caused us to lose our gn check certification. :(
Turns out gn check was just ignoring all the header
paths it didn't understand and so gn check passing
for sky wasn't meaning much. I tried to straighten
out some of the mess in this CL, but its going to take
several more rounds of massaging before gn check
passes again. On the bright side (almost) all of
our headers are absolute now. Turns out my script
(attached to the bug) didn't notice ../ includes
but I'll fix that in the next patch.
R=abarth@chromium.org
BUG=435361
Review URL: https://codereview.chromium.org/746023002
Fix (most) generated includes to have gen/ in their path.
This makes it easier to tell where files exist on disk.
Unfortunately I had to leave the old include path
in engine/BUILD.gn to support all the v8 includes
which were too many to deal with in this patch.
It's a little nasty to have the raw build directory
in our include path, but it produces nicer paths.
R=abarth@chromium.org
This just removes a random subset of vertical writing mode bits
that I grepped for. There's a ton more to do, but it seems best to
do it in chunks.
The key things for understanding this patch, isWritingModeRoot is
always false and isHorizontalWritingMode is always true. Also,
we're never flipped* modes of any kind, so we can undo any flipping.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/688213002
