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
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
Reason for revert:
This broke hit testing. Hit testing always returns the root node now. :)
Original issue's description:
> Remove RenderLayer::collectFragments.
>
> Sky always has exactly one per RenderLayer. This patch
> gets rid of the hitTestLayer use of LayerFragment
> and gets paintLayerContents to create the list of
> fragments itself since it's the only caller.
>
> Also, delete dead code from LayerFragment.h.
>
> R=abarth@chromium.org
>
> Committed: 4a3b676dc3TBR=esprehn@chromium.org,rafaelw@chromium.org,abarth@chromium.org,ojan@chromium.org
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/788383002
We don't have fragmentation. So no need for this abstraction.
This simplifies a lot of code so that we can do less work.
For example, we can check shouldPaintContent only up in
paintLayerContents instead of in each nested function.
Instead of passing the LayerFragment, pass the layer location
and the clip rect for each nested function.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/789643002
Sky always has exactly one per RenderLayer. This patch
gets rid of the hitTestLayer use of LayerFragment
and gets paintLayerContents to create the list of
fragments itself since it's the only caller.
Also, delete dead code from LayerFragment.h.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/778043005
Make it a regular enum and remove it from all the functions
it's not actually used. Also, make paintLayer and PaintLayerFlags
private since they're only used in RenderLayer.
R=eseidel@google.com
Review URL: https://codereview.chromium.org/779183004
Only PaintLayerPaintingOverlayScrollbars is actually ever set
to a different value in different codepaths.
-PaintLayerHaveTransparency can just be replaced with
isTransparent() calls.
-PaintLayerPaintingCompositingScrollingPhase is unused.
-PaintLayerPaintingCompositingAllPhases is always set,
which means that the other three compositing ones are
also always set.
The third bullet more clearly falls out when you see that
the only caller of paintLayerContents is
paintLayerContentsAndReflection, which sets
PaintLayerPaintingCompositingAllPhases on the paint flags.
Get rid of paintLayerContentsAndReflection since we no
longer have reflections.
The rest of the changes are all just propagating the now
always false or true booleans in paintLayerContents.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/778883002
It was added for compositing overflow:scroll, which we don't do.
This also means that only the RespectOverflowClip enum value is
used. And PaintingClipRectsIgnoringOverflowClip is unused.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/778753002
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
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
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
