This reverts commit c7950c03d7.
Revert "Bug 1984859 - Use a common type for layout rounded corners and graphics rounded corners. r=layout-reviewers,gfx-reviewers,jfkthame,jnicol"
This reverts commit 2991156989.
Revert "Bug 1984859 - Use Margin to represent border widths in nsCSSRendering. r=layout-reviewers,gfx-reviewers,jfkthame,jnicol"
This reverts commit 446150abe6.
Per spec of `rect()`, the second (right) and third (bottom) values are
floored by the fourth (left) and second (top) values, respectively. This
is to avoid that they don't cross over the other edge. In our
implementation, we just clamp width and height to make sure they are not
negative. The both ways should be identical.
Note that the spec also mentions another way to handle the similar case
in `inset()`, which would like to apply the algorithm mentioned in
"CSS Backgrounds 3 § 4.5 Overlapping Curves rules" to proportionally reduce
the inset effect to 100%. This may cause a different result from
flooring the values. I suspect this is a spec issue:
https://github.com/w3c/csswg-drafts/issues/10870.
Differential Revision: https://phabricator.services.mozilla.com/D222536
`at <position>` is optional value and we should omit it if author doesn't
specify it, for all basic-shape functions, and ray().
Note that there is a related interpolation issue [1] if one of the end values
doesn't specify `at <position>`. We didn't address this issue in this patch.
[1] https://github.com/w3c/csswg-drafts/issues/9068
Also, this updates the devtool code to give it the default value, "50% 50%",
for circle() and ellipse() if `at <position>` is not specified.
Differential Revision: https://phabricator.services.mozilla.com/D181918
Per spec
https://drafts.csswg.org/css-shapes-1/#basic-shape-computed-values, and
the spec issue, https://github.com/w3c/csswg-drafts/issues/9053,
all <basic-shape-rect> functions compute to the equivalent inset() function.
i.e.
`xywh(x y w h)` computes to
`inset(y calc(100% - x - w) calc(100% - y - h) x)`
The basic concept is to use `BasicShapeRect` as the specified value of
`<basic-shape-rect>`, i.e. inset()/xywh()/rect(), and its computed value is
the equivalent `InsetRect`, and so it becomes possible to interpolate among
these three functions.
Also, we can drop BuildXywhPath() and ComputeRect() because now there is
only inset() function when building gfx::Path.
Besides, tweak the test, offset-path-shape-xywh-003.html, because the original
test, `xywh(10% 10% 80% 80%)`, has to calculate `calc(100% - 10% - 80%)`.
Its result is `Percentage(0.099999964)` in Rust code, and then it makes us
compute an imprecision inset rect when building the gfx::path, which results in
a transform with the sub-pixel translation. So change it to
`xywh(10% 10% 90% 90%)` to avoid adding fuzzy tolerance.
Differential Revision: https://phabricator.services.mozilla.com/D183221
The fuzzy in the test happens on the round because we use the different way
to draw the round of clip-path (compared to border-radius property) in
the render backend, so there are some tiny differences.
Differential Revision: https://phabricator.services.mozilla.com/D182421
And rename some functions, e.g. BuildInsetPath as BuildRectPath and
ComputeInsetRadii as ComputeRectRadii, because we would like to use it for
inset()/xywh()/rect(). All of them define the similar rectangles.
Also, tweak the tests:
1. tweak offset-path-shape-xywh-001.html to avoid the element just at
the bottom-right corner of path because there is no tangent angle at this
point. Its direction angle could be 90deg or 180deg, depends on the
implementation.
2. tweak offset-path-shape-xywh-002.html and
offset-path-shape-xywh-002-ref.html together because it seems the
original ref file is incorrect. The test was added by Blink and the
implementation of xywh() in Blink uses the height of the reference box to
resolve the precentage value of the width of the transformed box.
It doesn't make sense because we should use the width of the reference box
to resolve it. So tweak the test and its reference file together
based on Gecko's result.
Differential Revision: https://phabricator.services.mozilla.com/D182420
We would like to use these function for all rectangular shape, i.e.
inset()/xywh()/rect(). So rename them to avoid confusion.
No behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D182422
I tweak css/motion/offset-path-coord-box-001.html a little bit to
avoid decimals in the reference file.
For offset-path-coord-box-002.html and offset-path-coord-box-003.html,
I make the border width larger so it'd be clear to see the difference.
Also the original reference files are not correct because they always use
border-box, so I also fix them to use the correct box.
Also, rename offset-path-geometry-box.html as offset-path-coord-box-004.html,
because there is no "geometry-box" in the spec. We are using "coord-box"
now.
Differential Revision: https://phabricator.services.mozilla.com/D181317
The omitted postion has special meaning for offset-path. It defaults to using
offset-position as the circle/ellipse center if the explicit center is
not given. Just like what we do for ray(), here we also use
PositionOrAuto for it.
We omit this component if it is not given when serializing offet-path,
and preserve the value even if it specifies the default value, for the
same reason.
For shape-outside and clip-path, we don't change their behaviors for now.
This bug is for offset-path and we will use it in the following patches.
We should fix them in Bug 1837340.
Differential Revision: https://phabricator.services.mozilla.com/D179626
We apply offset-position and "at <position>" to ray function. However,
only use it on the main thread. For compositor animation, we will finish
it in the following patches.
No need to add tests because there are tests in the WPT upstream repo already:
css/motion/offset-path-ray-011.html
css/motion/offset-path-ray-012.html
css/motion/offset-path-ray-013.html
css/motion/offset-path-ray-014.html
Those tests should cover what we do in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D179861
And move the useful bits of it somewhere else (ServoStyleConstInlines.h for the
inline function definitions, and nsFrame.cpp for the static assertions).
Differential Revision: https://phabricator.services.mozilla.com/D36120
And move the useful bits of it somewhere else (ServoStyleConstInlines.h for the
inline function definitions, and nsFrame.cpp for the static assertions).
Differential Revision: https://phabricator.services.mozilla.com/D36120
This enables destructors for tagged unions in cbindgen, implemented in:
* https://github.com/eqrion/cbindgen/pull/333
Which allow us to properly generate a destructor for the cbindgen-generated
StyleBasicShape (which now contains an OwnedSlice).
For now, we still use the glue code to go from Box<BasicShape> to
UniquePtr<BasicShape>. But that will change in the future when we generate even
more stuff and remove all the glue.
I could add support for copy-constructor generation to cbindgen for tagged
enums, but I'm not sure if it'll end up being needed, and copy-constructing
unions in C++ is always very tricky.
Differential Revision: https://phabricator.services.mozilla.com/D29769
It doesn't make much sense to return const UniquePtr<Foo>& for something that
can't be null, it's just confusing.
Also make more stuff actually const.
Differential Revision: https://phabricator.services.mozilla.com/D10647
After StyleBasicShape is set to StyleShapeSource, it's life cycle never go
beyond StyleShapeSource, so I make StyleBasicShape hold by a UniquePtr in
StyleShapeSource.
Also, replace all raw pointers to StyleBasicShape by UniquePtr in all APIs.
MozReview-Commit-ID: 1MfIFjP8TsQ
Mr. M