-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
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
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
We only need to walk the immediate children of the paragraph.
The other inline children of the paragraph will get paint called
on them and they will then appropriately add the self painting
layers to the array inside their paint calls.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/945223002
-ASSERT(layer()->parent()) in all the transform codepaths since
the RenderView cannot have a transform.
-Early return if the content rect does not intersect the
damage rect in the painting code. We don't need to do
any of the filter and/or transparency dance if we're
not going to paint anything. This also allowed for
removing the shouldPaintContent bool.
-Remove a random style() null check that can't be hit.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/950553002
The only bit that was still used was the
containingBlockLogicalWidthChanged check in
RenderBlock::widthAvailableToChildrenHasChanged.
a4f1e657ff
is the patch that added that code. I added a
test to confirm we still pass the test case
that code was added for.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/945003002
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
The use-cases we care about are met better by translate2d.
Remove the parsing so that people writing on sky don't
depend on it. Followup patches will remove the functionality.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/904613005
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
Normal trace events already go directly to base. This CL removes the remaining
trace events that were still indirected through blink::Platform. These were
just the half-finished inspector timeline trace events, which currently aren't
actually hooked up to anything.
This CL also removes the redunant "convertable to trace format" wrappers and
moves their one remaining use over to just using the version in base directly.
R=eseidel@google.com, ojan@chromium.org
Review URL: https://codereview.chromium.org/889823002
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
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
We've simplified RenderBlock::layout to the point where we
no longer need it or layoutBlock. The RenderBlock subclasses
can just override layout the way every other renderer does.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/876663003
