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
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
This just removes a random subset of vertical writing mode bits
that I grepped for. There's a ton more to do, but it seems best to
do it in chunks.
The key things for understanding this patch, isWritingModeRoot is
always false and isHorizontalWritingMode is always true. Also,
we're never flipped* modes of any kind, so we can undo any flipping.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/688213002
I used do-webcore-rename from Blink/WebKit
which is very good at doing this kind
of search-replace.
Also removed toRefPrtNativeArray after
conversion since it previously had two
separate flavors. Both versions are no longer
used so I've removed the code until we
need one again.
https://www.irccloud.com/pastebin/5C16p5cE
is the diff I used to do-webcore-rename
TBR=abarth@chromium.org
