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
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
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
First step in getting rid of paint phases. Verified that
deleting this phase entirely would cause flights-app-pixel.sky
to fail and that it still passes in this patch, which just does
the background painting as part of the foreground phase.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/867463005
This was used for quirky scrollbar behavior on the web related to
which element defined in the viewport (body, html, etc.). In Sky we plan to
allow multiple elements as direct children of the Document so we need to get
rid of checks like this. The good news is this already does nothing in sky
because the root never has scrollbars automatically.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/858713002
This is an optimization to avoid painting backgrounds
that are obscured. It's a lot of complexity that it's
not clear we'll need given that we're using a GL backend.
Also, we can add it back in more easily/efficiently in the future
once we have a display list architecture.
This also means we can remove the needsPaintInvalidation
dirty bit and some opacity information on filters.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/856563006
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 is all wasted effort in sky since we invalidate
the whole viewport on every frame. We'll probably eventually
add back in some invalidation, but it likely won't
be rect-based.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/840403003
e223e0c6d51f027196a2597b556641328a65d4b5 accidentally
sent all elements down the margin:auto codepath.
The patch incorrectly removed just the
"&& containingBlockStyle->textAlign() == WEBKIT_CENTER"
instead of the whole clause.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/760143002
Particularly, this deletes RenderLayerCompositor. After this,
there's just CompositingState left to remove.
This is all dead code, so there should be no change in behavior.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/758843004
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
-Add RenderParagraph and display:paragraph. This is the only
render type that's allowed to contain inlines or text.
-If you put text nodes directly in a non-paragraph, wrap them
in an anonymous paragraph. This may not be the place we want
to end up, but it's a good stopgap to make it so we don't
crash in this case.
-Make StyleAdjuster force that non-paragraph blocks only contain
RenderBlock subclasses and that paragraphs and inlines only contain
inlines.
-Considerably simplify addChildIgnoringAnonymousColumnBlocks
now that we only create anonymous blocks for the case of
text nodes in non-paragraphs. Also get rid of the behavior
where we try to group multiple nodes into a single
anonymous block.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/729693003
We never paint scroll corners. The only thing we need them
for is so that the vertical and horizontal scrollbars don't
overlap each other. So, that's the only place left that
still computes a scroll corner rect.
We don't support resizers. Remove the code for them as well
as the CSS resize property.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/689283003
These are values for text-align that align blocks in addition to
inline content. You can get the same centering affect with margin:auto.
If we want this functionality, we should implement it with the
same alignment APIs that we use for flexbox.
Delete unused methods/arguments from RenderBlockFlow.
No change in behavior. Just deleting dead code.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/708843002
Margin collapsing is a document-oriented feature. For applications
it just causes confusion and slowness.
margins.sky has failure output because offsetTop is returning the
wrong values. That's not new with this patch though. When I look
at it visually in skydb, everything seems to be in the right place.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/700743002
The two are unrelated, but it was easier to just grep for grid
and remove them all. Aside from the media query change, there
isn't any change in behavior since grid was behind a flag.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/689853003
