With this gone, cursors will no longer change
on hover when running Sky on a desktop.
Then again the iGeneration doesn't
probably even know what a mouse is, let alone
have a burning desire to set a CSS3 custom-cursor.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/1076623002
We only ever create RenderParagraphs now. The only non-trivial change here
is making RenderView a RenderFlexibleBox. This required changing custom.sky.
That test was written in a fragile way that behaved differently if we
did multiple layouts. Instead, having it be less racy and only change
values during the test itself.
This also throws a wrench in moving all the layout code to dart
because we can't set the layout manager on the RenderView. Maybe
we need to explicitly let you do so.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1068683002
-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
-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
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
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
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
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
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
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
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
-Add RenderParagraph and display:paragraph. This is the only
render type that's allowed to contain inlines or text.
-If you put text nodes directly in a non-paragraph, wrap them
in an anonymous paragraph. This may not be the place we want
to end up, but it's a good stopgap to make it so we don't
crash in this case.
-Make StyleAdjuster force that non-paragraph blocks only contain
RenderBlock subclasses and that paragraphs and inlines only contain
inlines.
-Considerably simplify addChildIgnoringAnonymousColumnBlocks
now that we only create anonymous blocks for the case of
text nodes in non-paragraphs. Also get rid of the behavior
where we try to group multiple nodes into a single
anonymous block.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/729693003
