Make DisplayList hit testing a method on DisplayList
This will allow us to hit test into DisplayLists that are not directly
contained in StackingContexts, but instead are children of PaintLayers.
It also makes things slightly simpler.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7751)
<!-- Reviewable:end -->
layout: Make the compositor rather than layout determine the position of each iframe.
The old code that attempted to do this during layout wasn't able to work
for multiple reasons: it couldn't know where the iframe was going to be
on the page (because of nested iframes), and at the time it was building
the display list for a fragment it couldn't know where that fragment was
going to be in page coordinates.
This patch rewrites that code so that only the size of an iframe is
determined during layout, and the position is determined by the
compositor. Layout layerizes iframes and marks the iframe layers with
the appropriate subpage ID so that the compositor can place them
correctly.
Closes#7377.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7423)
<!-- Reviewable:end -->
each iframe.
The old code that attempted to do this during layout wasn't able to work
for multiple reasons: it couldn't know where the iframe was going to be
on the page (because of nested iframes), and at the time it was building
the display list for a fragment it couldn't know where that fragment was
going to be in page coordinates.
This patch rewrites that code so that both the sizes and positions of
iframes are determined by the compositor. Layout layerizes all iframes
and marks the iframe layers with the appropriate pipeline and subpage
IDs so that the compositor can place them correctly. This approach is
similar in spirit to Gecko's `RefLayer` infrastructure. The logic that
determines when it is time to take the screenshot for reftests has been
significantly revamped to deal with this change in delegation of
responsibility.
Additionally, this code removes the infrastructure that sends layout
data back to the layout task to be destroyed, since it is now all
thread-safe and can be destroyed on the script task.
The failing tests now fail because of a pre-existing bug related to
intrinsic heights and borders on inline replaced elements. They happened
to pass before because we never rendered the iframes at all, which meant
they never had a chance to draw the red border the tests expect to not
render!
Closes#7377.
This will allow us to hit test into DisplayLists that are not directly
contained in StackingContexts, but instead are children of PaintLayers.
It also makes things slightly simpler.
gfx: Fix border-radius panic when a corner has 0px and >0px borders
When one border is 0px and the other is >0px then the border corner
drawing code panics when computing the values to use in drawing the
border corner arcs.
This fixes that bug and makes the `draw_corner` function more robust
by explicitly passing an enum, `BorderCorner`, naming which corner is
being drawn e.g. `BorderCorner::TL`.
Add a ref test,
`border_radius_zero_sizes_a.html/border_radius_zero_sizes_ref.html`.
Fixes https://github.com/servo/servo/issues/7700.
r? @pcwalton or @mbrubeck
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7703)
<!-- Reviewable:end -->
A few small bits of refactoring to prepare for more advanced DisplayList layerization
This will be useful when PaintLayers that contain DisplayLists instead
of StackingContexts need to draw themselves. This is a simple
preparatory refactoring and doesn't change any behavior.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7710)
<!-- Reviewable:end -->
This will be useful when PaintLayers that contain DisplayLists instead
of StackingContexts need to draw themselves. This is a simple
preparatory refactoring and doesn't change any behavior.
When one border is 0px and the other is >0px then the border corner
drawing code panics when computing the values to use in drawing the
border corner arcs.
This fixes that bug and makes the `draw_corner` function more robust
by explicitly passing an enum, `BorderCorner`, naming which corner is
being drawn e.g. `BorderCorner::TL`.
Add a ref test,
`border_radius_zero_sizes_a.html/border_radius_zero_sizes_ref.html`.
Fixes https://github.com/servo/servo/issues/7700.
Add css twitter fail whale html test & update ellipse_to_bezier comment
cgaebel had a TODO for a css twitter fail whale reftest, which depended on elliptical border-radius support.
I didn't see any feasible way other than a reference image for border_twitter_fail_whale_b.html.
r? @pcwalton
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7679)
<!-- Reviewable:end -->
Currently pseudo-elements, like the fragments created for ::before and
::after, with layers will have the same LayerId as the body of their
owning fragments. Instead all LayerIds should be unique.
Fixes#2010.
Remove 'get_*' on getters as per RFC 0344 on canevas, compositing, devtools, gfx, layout, net, profile, servo and webdriver_server
Hi guys,
I just gave a big pass of RFC-0344 as per issue #6224 .
Pretty much renamed all the get_* fn that were used to fetch values.
I hope I didn't rename too much.
As said in the issue discussion, I didn't touch at the scripts folder so we keep the unsafe ones pretty explicit.
I've ran the whole pass of test, everything seems to be still working right :).
Please give feedback on this PR.
Thanks for looking into it.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7559)
<!-- Reviewable:end -->
Use SIMD in fast path for advance_for_char_range
In advance_for_char_range add a fast SIMD code path for the the common
case where there are no detailed glyphs.
r? @mbrubeck
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7527)
<!-- Reviewable:end -->
In advance_for_char_range add a SIMD code path for the the common
case of no detailed glyphs.
- gfx/Cargo.toml
Add simd dependency https://github.com/huonw/simd
- servo/Cargo.lock
Add simd dependency https://github.com/huonw/simd @
d9ad79d86eab50a8f36d45fe17aa9e3a533389ee.
- SIMD isn't used on non-x86_65/aarch64 architectures.
gfx: Fix bug with 1px width borders disappearing
In to_nearest_azure_rect when rounding to pixel coordinates, maintain
the invariant of rect non-overlap (if before rounding two rects don't overlap).
The previous code rounded the rect top left corner to the nearest pixel with
the size rounded to the nearest pixel multiple which can violate the
non-overlap condition, e.g.
10px×9.60px at (0px,6.6px) & 10px×9.60px at (0px,16.2px)
would round to
10px×10.0px at (0px,7.0px) & 10px×10.0px at (0px,16.0px), which overlap.
Instead round each corner to the nearest pixel.
For rects that dont need to satify the non-overlap condition and with
width or height between 0.5px and 1px, rounding each rect corner to the
nearest pixel can yield an empty rect e.g.
10px×0.6px at 0px,28.56px -> 10px×0px at 0px,29px.
For this scenario a new function to_nearest_non_empty_azure_rect
rounds the rect top left corner to the nearest pixel and the rect size
to the nearest pixel multiple. It's possible for non-overlapping rects
after this rounding to overlap.
This should fix https://github.com/servo/servo/issues/7184 "rounding ...borders not to be visible", without breaking https://github.com/servo/servo/issues/7152 "Underlines less than 1px high sometimes invisible".
r? @mbrubeck
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7577)
<!-- Reviewable:end -->
Layerize StackingContexts that are on top of layers
StackingContexts that should be painted on top of StackingContexts that
are already layerized should automatically get their own layer. This
will ensure proper painting order.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7563)
<!-- Reviewable:end -->
StackingContexts that should be painted on top of StackingContexts that
are already layerized should automatically get their own layer. This
will ensure proper painting order.
