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.
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.
Have PaintLayers own StackingContexts instead of the opposite
Previously, StackingContexts might have a PaintLayer. We switch the
ownership, for several reasons:
* We want PaintLayers to potentially contain something other
than a StackingContext soon.
* We want to delay the creation of PaintLayers until the last
minute, so that we can synthesize new layers for sandwiched
content.
This commit also implements the second goal. Instead of creating
PaintLayers during layout itself, wait until we are sorting and
layerizing a completed DisplayList.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7487)
<!-- Reviewable:end -->
Previously, StackingContexts might have a PaintLayer. We switch the
ownership, for several reasons:
* We want PaintLayers to potentially contain something other
than a StackingContext soon.
* We want to delay the creation of PaintLayers until the last
minute, so that we can synthesize new layers for sandwiched
content.
This commit also implements the second goal. Instead of creating
PaintLayers during layout itself, wait until we are sorting and
layerizing a completed DisplayList.
layout: Make overflow calculation take relative percentages into account.
This necessitated changing overflow to be calculated by the parent flow
if relatively positioned children are present. That is because the
overflow regions cannot be calculated without knowing relative offsets,
which themselves cannot be calculated without knowing the parent size
(because of percentages). To accomplish this without sacrificing
parallelism in the non-relative case, this patch splits overflow into
"early" and "late" computation. Late overflow computation cannot be
parallelized across children, while early overflow computation can.
Makes the "Apple Music" text show up over the full-bleed promotional
background on apple.com.
r? @SimonSapin -- would appreciate a look over the iframe test case that was changed.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7313)
<!-- Reviewable:end -->
gfx: Border radius support for asymmetric sized borders
When the border-top/right/bottom/left-widths are not equal, the angle on the border corner arc separating the borders isn't PI/4.
For instance if the top border width is much larger than the left border width then most of the border corner should be drawn using the top border color.
This change adds support for calculating the correct angle in the border
corner arc for switching from one border to another e.g. the left border
to the top border.
It supports elliptical border radii for when elliptical border radii are
added.
A ref test is also included.
r? @Ms2ger
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7370)
<!-- Reviewable:end -->
This change adds support for calculating the correct angle in the border
corner arc when switching from one border to another e.g. the left border
to the top border.
When the border-top/right/bottom/left-widths are not the same, the angle on
the border corner arc separating the borders isn't pi/4.
For example, if the top border width is much larger than the left border
width then most of the border corner should be drawn using the top
border color.
Elliptical border radii are supported for when elliptical border radii are
added.
The common case where borders have the same width sets the angle to
pi/4 directly.
A ref test is also included.
Split out layered child stacking contexts in display lists
This patch is in preparation for more dynamic layerization of the
pieces of display lists. It also prevents having to sort the children
by z-index multiple times.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7392)
<!-- Reviewable:end -->
This patch is in preparation for more dynamic layerization of the
pieces of display lists. It also prevents having to sort the children
by z-index multiple times.
