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.
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 -->
