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
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
blink::EventHandler is really hairy and deals with a lot of complex cases that
don't matter for Sky. This CL starts a NewEventHandler and adds support for
PointerEvents there. The NewEventHandler will eventually replace EventHandler
once we've actually migrated over from Mouse+Touch events to PointerEvents.
R=esprehn@chromium.org, ojan@chromium.org, eseidel@chromium.org
Review URL: https://codereview.chromium.org/823873004
Previously, if you had a generated background image and a translucent (or
rounded) border, we would draw the image nine times because we would inflate
the fill rect to draw behind the border. With no-repeat, we only draw the image
once.
This saves 4.5% of record time on flights-app.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/844193009
Instead, always use InterpolationLow. In Skia, that boils down to bilinear,
which is fast on GPUs. We should eventually let authors control the
interpolation quality in case they want pixelation, etc.
This CL saves 6.3% on Layer::RecordPicture for flights-app.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/860843006
I believe this doesn't change behavior, but it's hard
to know since we don't have spellchecking hooked up.
Also, delete setToolTip. This is for tooltips on spelling
markers. We don't support tooltips.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/830273006
This removes the attributes sky doesn't intend to support. It
removes references to the attrs, but leaves behind a lot of
plumbing that will be cleaned up in the future. This at least
removes the API surface.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/855803002
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
The only thing they're used for now is to clear the
background obscuration state on RenderBox. They're
also used in RenderLayerModelObject::styleWillChange,
but that usage seems like a huge premature optimization.
Unfortunately, the RenderBox one walks up the ancestor
chain, so it's likely a necessary performance optimization.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/851033002
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
