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
-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
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
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
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
Change hit testing to walk over the render tree instead of
the RenderLayer tree. This is a step in the direction of
removing the RenderLayer tree entirely.
For now, there's a few calls back into RenderLayer that
will be removed in a followup patch. This patch also
breaks hit testing on transformed inlines. I'll be
removing the ability to transform inlines in a
followup patch anyways, so it's ok for hit testing
to give the wrong result temporarily here.
Almost all of this patch is just moving code from
RenderLayer to RenderBox. The primary substantive change
is in RenderBox::hitTestLayer. Instead of having
hitTestChildren calls, we call collectSelfPaintingLayers,
reverse sort by z-index (so we start at the top),
and then iterate over the result.
The test-case also exposes that we don't correctly hit
transformed elements inside inline-blocks. I went back as
far as 4153b8a515d54275934d4244aaf2d5a7a8fe3333 and the
bug still happened.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/945693002
This makes hitTestLayer a bit larger at the benefit of making
the code a bit easier to follow and getting rid of the confusing
recursive call to hitTestLayer and the appliedTransform bool.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/937023002
I'm not 100% what this was for, but looking at Blink,
it appears that HitTestChildBlockBackground being different
from HitTestBlockBackground had something to do with
multi-column/regions, which we don't have. I believe
this patch doesn't change any behavior.
Also added to the elementFromPoint test in order to
get more test coverage of the hitTesting code.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/924263002
Prunes a bunch of dead code from HitTestResult and
stops special-casing links for creating hand cursors.
This code already isn't working today anyways, so
in practice, there's no change in behavior.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/925933004
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
Commit efc3afd428bd85fd3d12e0dc941b5eb7248ca30b broke it because
we'd computed an empty foreground layer. Now that background
painting is part of the foreground phase, we need to use the
background rect for clipping. As best I can tell, the
background rect is always >= the size of the foreground
rect, so it should be safe to use.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/876243002
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 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
