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
There are some cases in this patch where it's not
obvious that the code only applies to position:relative,
but the code asserts that it does. In those cases,
I trusted the asserts and deleted the code.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/938193004
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
Jagged edge outlines are more complexity than is justified
for the use-cases. We should enable to use-cases like this,
but with a lower-level line-box + custom painting API.
Removes the paintOutline method on RenderInline. Also removed
a number of dead methods that call absoluteRects so we can delete
that method and related code.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/867653005
Delete selection paint invalidation code.
There is a slight change in behavior in FrameSelection::revealSelection.
If you have a non-collapsed selection, then we'll center the start
of the selection instead of the whole selection in some cases. There's
a ton of callers of this code, so it's hard to be sure if any of this
actually changes behavior for sky. In manual testing, I couldn't find
any scenarios where there was a difference. Almost universally,
when we call revealSelection, we have a CaretSelection. The only
case I could think of where we have a RangeSelection is when
modifying an off-screen selection (e.g. shift+right), but in that case
we pass the RevealExtent option, so this patch doesn't change behavior
there.
Removing that caller makes all the rest of this rect computing
code into dead code.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/823123003
There is a slight change in behavior in FrameSelection::revealSelection.
If you have a non-collapsed selection, then we'll center the start
of the selection instead of the whole selection in some cases. There's
a ton of callers of this code, so it's hard to be sure if any of this
actually changes behavior for sky. In manual testing, I couldn't find
any scenarios where there was a difference. Almost universally,
when we call revealSelection, we have a CaretSelection. The only
case I could think of where we have a RangeSelection is when
modifying an off-screen selection (e.g. shift+right), but in that case
we pass the RevealExtent option, so this patch doesn't change behavior
there.
Removing that caller makes all the rest of this rect computing
code into dead code.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/847303003
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
