When ths path length is zero, we may get (0, 0) as the tangent angle
from `ComputePointAtLength()`. Using (0, 0) to atan2() may get an
undefined result. We should avoid this, so use 0rad. This makes more
sense and match other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D220353
We treat it as other basic shapes (excluding path(), which has some
special handling and it doesn't rely on the current layout position).
Therefore, we don't have any implementation for caching and we would like to
leave this part to Bug 1837042.
Also, add some more simple tests in css/motion to make sure we render it
properly.
Differential Revision: https://phabricator.services.mozilla.com/D204440
Also, we don't have Unkonwn type, so we have to do some minor
refactoring in BuildPath(), and templatize this function so we can use
it for both shape() and path().
This patch doesn't change the behavior.
Note that we instantiate BuildPath() with CSSFloat for now. Once we
instantiate it for StyleAngle and LengthPercentage (i.e. shape()), we
have to tweak this function more. Let's do that in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D202883
Implement the style part for shape(). Besides, update some issues in the
test file, e.g. avoid using viewport height so we get the fixed result
on different devices.
I will refactor `PathCommand` to let it be a specialization of
`GenericShapeCommand` in the following path.
Differential Revision: https://phabricator.services.mozilla.com/D202882
While we are computing the transform-box:stroke-box, for CSS Transforms or
Motion path Transforms, we have to avoid the cyclic dependency not only
for the SVG geometry frame itself, but also for the desendants of
the SVG container frame. Therefore, we just compute its fill-box (i.e.
make |getStroke| be false).
https://github.com/w3c/csswg-drafts/issues/9640
Differential Revision: https://phabricator.services.mozilla.com/D203184
Extend the per-frame-class bit we have to devirtualize IsLeaf to also
devirtualize IsFrameOfType. That is, move this data to FrameClasses.py.
This was done by going through all the frame classes, trying to preserve
behavior.
The only quirky thing is that I had to add two more trivial frame
classes, `nsAudioFrame` for audio elements, and
`nsFloatingFirstLetterFrame`. That's because these frame classes were
returning different answers at runtime, but they do this only on
conditions that trigger frame reconstruction (floating, and being an
audio element, respectively).
Differential Revision: https://phabricator.services.mozilla.com/D194703
It looks like our formula doesn't work well for 0deg and 90deg because
it's not a triangle when theta is 0deg or 90deg. So we handle them
separately.
Differential Revision: https://phabricator.services.mozilla.com/D191495
Also, drop `nsLayoutUtils::ComputeGeometryBox()` and avoid doing mapping
in `ComputeHTMLReferenceRect()` and `ComputeSVGReferenceRect()`. The
caller should handle it properly because each property uses its own mapping
between CSS box and SVG box.
Note:
1. mask-clip-3.html is copied from mask-clip-1.html but just replace
css boxes with svg boxes.
2. mask-clip-4.html is copied from mask-clip-2.html but just replace
svg boxed with css boxes.
Differential Revision: https://phabricator.services.mozilla.com/D188316
Also, add a prefernce for content-box and stroke-box. So we have to
define a new type, TransformBox, and let content-box and stroke-box
behind the preference.
Differential Revision: https://phabricator.services.mozilla.com/D185363
Also update offset-path-url-001.html because it seems its ref html is
incorrect per the spec. We are using its `<coord-box>` (i.e. the reference box
of its containing block) as the viewport and user coordinate system, so its
offset-starting-position should be independent from its current position
from CSS reflow. The SVG shape element always provides the offset starting
position.
So I tweak offset-path-url-001.html a little bit to make it passed for all
browsers, and add some other tests to cover the case mentioned above and
other cases.
Differential Revision: https://phabricator.services.mozilla.com/D184431
Per https://drafts.fxtf.org/motion/#path-distance, we follow these rules
when `offset-path` references to a SVG shape:
1. Offset paths (including references to SVG Paths) are closed loops only if
the final command in the path list is a closepath command ("z" or "Z"),
otherwise they are unclosed intervals.
2. References to SVG circles, ellipses, images, polygons and rects are closed
loops.
3. References to SVG lines and polylines are unclosed intervals.
Also, rename `mIsClosedIntervals` as `mIsClosedLoop` to be consistent.
Differential Revision: https://phabricator.services.mozilla.com/D184430
In layout, we build a default `path("m 0 0")` for now. We will implement
it later.
Besides, we don't support compositor animations for `url()`, so we don't
have to serialize it for IPC.
Note:
`<url>` includes `url()` and `src()`. For now we only support `url()`.
We should revisit `src()` in Bug 1845390.
Differential Revision: https://phabricator.services.mozilla.com/D184429
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
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
This patch sends the information of border-radius to the compositor as
well, so we can use it if offset-path uses coord-box only.
Note:
We repaint the frame if border-radius property gets changed, and rebuild
the display item. In this case, we resend the transaction of compositor
animation as well. Therefore, we don't have to block the compositor animations
if they depends on border-radius (i.e. use coord-box only).
We may need a better way to check what should we pass to the compositor,
for motion path, in Bug 1838977.
Differential Revision: https://phabricator.services.mozilla.com/D179631
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
Basically, the fuzzy happens because the direction angle in circle(),
ellipse(), and inset() can not be equal to the degree perfectly (due to
the arc drawing implementation and the anti-alias around the element),
so we need some tolerance.
And drop offset-path-shape(-ref).html because it has been removed from
the upstream repo.
Differential Revision: https://phabricator.services.mozilla.com/D179630
The data structure of StyleOffsetPath is complicated, so adding some
useful functions to simplify the code.
No behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D181316
I'd like to reuse it to compute the center position for circle() and
ellipse(), so use a better function name.
No behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D181315
I'd like to reuse the data in RayReferenceData for all basic shapes,
so unpack RayReferenceData and drop this struct.
Also, use `nsPoint` for the current position and use `nsRect` for coord-box
because we use these types (i.e. app units) in ShapeUtils.
Besides, remove the usage of Maybe from nsStyleTransformMatrix.h and
just accept the pointer of ResolvedMotionPathData to avoid including
the entire header.
No behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D181008
So now we use <coord-box> to decide which box we should use. Also, we
have to tweak the calculation of path length to take the top left point
into consideration, for padding-box and content-box. border-box is the
default value, so other tests should cover it.
Differential Revision: https://phabricator.services.mozilla.com/D180397
We are using NonNegative now for offset-path, so just like clip-path, we
have to make sure we don't get the negative radius for circle and ellipse,
and don't get the negative border-radius for inset. Therefore, we have to
convert the computed value into animated value when doing interpolation,
and then clamp the value to make sure it is always >= 0 when converting
it back to computed value, just like what we do for clip-path in Bug 1512883.
Also drop the normalization of SVGPathData in AnimationInfo when
preparing offset-path for compositor animations. It's useless because we
"always" do normalization in SVGPathData::animate().
Differential Revision: https://phabricator.services.mozilla.com/D180284
We rewrite the data structure of OffsetPath to support all basic shapes.
However, We don't build the gfx::Path for basic shapes other than path()
for now because the current caching mechanism (on the main thread) doesn't
work for basic shapes. It's layout dependent.
Note:
1. Update offset-path-interpolation-006.html to make sure the start value
and the end value have `at <position>`. `offset-path` doesn't set center
as default for `at <position>`, so if any of the values omits the
`at <position>`, we expect they are not interpolated in Gecko.
This is different from Blink, they still use center as the default value
for interpolation.
2. We still have some failures in offset-path-interpolation-006.html
beacuse we don't clamp the negative radius/radii and the negative
border-radius. We will handle it in the following patches.
3. We will add `<coord-box>` in the later patch.
4. Adding Deserialize and Serialize is necessary for compositor
animations.
Differential Revision: https://phabricator.services.mozilla.com/D179627
We send offset-position to the compositor, just like other similar
properties, e.g. offset-rotate, offset-anchor. This includes extracting
this animation value, doing serialization and sending it via IPC.
So now we can run the animation of ray() on the compositor properly.
Differential Revision: https://phabricator.services.mozilla.com/D179862
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
Per the spec change, when using contain keyword, the path’s length is reduced
by half the width or half the height of the element’s border box, whichever is
larger, and floored at zero.
Differential Revision: https://phabricator.services.mozilla.com/D177563
[Int]CoordTyped no longer inherits Units because otherwise
instances of [Int]IntPointTyped may get one Base subobject because
it inherits Units, and others because of BasePoint's Coord members,
which end up increasing the [Int]CoordTyped's objects size (since
according to the ISO C++ standard, different Base subobject are
required to have different addresses).
Differential Revision: https://phabricator.services.mozilla.com/D160713
After the fixes in this patch, the REQUIRES_UNIFIED_BUILD declaration is no
longer needed, so I'm removing it here. This directory now builds successfully
with that removed and with ac_add_options --disable-unified-build in the
mozconfig.
Differential Revision: https://phabricator.services.mozilla.com/D125601
Also: adjust include paths to be consistent for usages of various SVG headers,
and remove unused SVG includes (mostly for "utils" classes),
and drop stray "ns" from already-renamed SVG classes in various code comments.
Differential Revision: https://phabricator.services.mozilla.com/D83140
To avoid computing transform bounds over and over. It is generally just better.
Replace the various "overridebounds" thingies by using the "fallback" of the
transform-reference-box code which we need anyway.
Differential Revision: https://phabricator.services.mozilla.com/D61890
Per SVG2 spec, the EBNF allows the path data string to be empty.
An empty path data string disables rendering of the path.
Therefore, we should make path('') a valid path string.
The related spec issue: https://github.com/w3c/fxtf-drafts/issues/392.
Now we serialize `path("")` as `path("")` for offset-path and clip-path.
Differential Revision: https://phabricator.services.mozilla.com/D60771
When we apply the transformation on the <g> element, its transformation also
performs on its child elements. So Motion-path should also work well in this
case.
For offset-path:path(), we have to make sure the element is on the svg path, no
matter what is its x and y values. That's why we have to calculate the
the frame position of the transformed SVG element if transform-box is fill-box.
However, for <g> element, its nsIFrame::GetPosition() is (0, 0), so we have to
calculate the geometry bbox instead, to make sure it works well on <g> or other
svg transformed elements.
Differential Revision: https://phabricator.services.mozilla.com/D55888
In most cases, we run an animation on an object by changing its
offset-distance/offset-rotate, but keep its offset-path the same.
Building and flattening the path is sometime expensive, especially for
large path, so caching it makes sense to us and have a significant
performance improvement. This is for the main thread motion path
animations.
Note: Even though we support compositor animations for motion path,
nsIFrame::GetTransformMatrix() is still called during the animations for
other usages, so we may still build the gfx::Path on the main thread
without this patch, so this improvement becomes necessary for most cases.
Differential Revision: https://phabricator.services.mozilla.com/D46667
This also includes the implementation of SetAnimatable, FromAnimatable,
and merge the final matrix with motion path.
Besides, we always use PathBuilderSkia for calculating the gfx::Path for
web-renderer.
Differential Revision: https://phabricator.services.mozilla.com/D50011
On the compositor thread in GPU process (i.e. web-renderer), gfxPlatform() is
not initialized, so we don't have the DrawTarget information.
Fortunately, all we need is to calculate the motion point and direction
vector, so we don't have to care about which backend we use.
Therefore, make PathBuilder as a parameter, so we can just pass a valid
PathBuilder on the compositor thread. For main thread (i.e. content
process), using the original way is fine.
Differential Revision: https://phabricator.services.mozilla.com/D50010
Boris Chiou