ShapeInfo and its derived classes are private to nsFloatManager, which don't
need to be in the header. Move them to cpp to make compile faster after
changing them.
MozReview-Commit-ID: MRkBGoqcPj
--HG--
extra : rebase_source : bc1de4269629f881e49af0d4faba89e8fbd4e460
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
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
--HG--
extra : rebase_source : bdbbd47de57e0bc610e37913752ab8413f62588a
The <fill-rule> in the polygon() syntax is not handled because it doesn't
matter to shape-outside at all.
The reftests are numbered from 018 to avoid conflict with the w3c upstream
ones according to this list.
https://test.csswg.org/harness/results/css-shapes-1_dev/grouped/
Reftest 018 to 025 are under various writing-modes, 026 to 029 are testing
empty float area, 030 to 031 are testing polygon containing horizontal
lines.
MozReview-Commit-ID: FPUbMdZsvu6
Remove WritingMode parameter from LineRight() and LineLeft() in both
FloatInfo and ShapeInfo.
Bug 1316549 Part 3 added the parameter to compute the border radii under
writing-modes correctly. However, bug 1326407 Part 6 later made us cache
border radii, so the WritingMode parameter is no longer needed.
MozReview-Commit-ID: DFhm5d51OXJ
The reftests have passed
layout/reftests/w3c-css/submitted/check-for-references.sh.
MozReview-Commit-ID: JZk1fo8SxgV
--HG--
extra : rebase_source : 5010c7e32bfe383c855ea5899f84860c4c747658
The radii has been cached in the BoxShapeInfo in the previous part. Hence
the rename.
This class will be used to implement inset() in the next part, so the rect
stored isn't necessarily the rect of the <shape-box>. It could be the inset
rectangle. Therefore I rename mShapeBoxRect to mRect to avoid any confusion.
MozReview-Commit-ID: J0hpQDsbMyN
--HG--
extra : rebase_source : 76cf50e1819a586199934c29f46d467a1b86a9ec
The radii can be computed when creating BoxShapeInfo. No need to compute
them every time in the LineLeft() and LineRight().
MozReview-Commit-ID: GIDSLgickCT
--HG--
extra : rebase_source : 53bcb9bb89dc254119be00f6d091797bdbbec9af
Make the name and the order of arguments be consistent with the
ConvertPhysicalToLogical() method added in the previous part.
MozReview-Commit-ID: 1YARDzI3cyr
--HG--
extra : rebase_source : 41dfc4bf09610a5a38fed281d4a65157cf474503
The life cycle of nsFloatManager managed by mNew is same as
nsAutoFloatManager, which lives only in nsBlockFrame::Reflow(). Therefore,
other nsFloatManager pointers are all non-owning ref to the
nsAutoFloatManager::mNew.
MozReview-Commit-ID: B34BOcsjE2X
--HG--
extra : rebase_source : 49e4adaf31537b4003ee1a3db315f3e8bd8b1a7f
The difference between CircleShapeInfo's constructor and EllipseShapeInfo's
is the computation of the radii. Therefore, this patch creates a factory
function to distinguish that, so shape-outside: circle() could be
implemented by using EllipseShapeInfo.
MozReview-Commit-ID: 9ZBQu8zCSrM
Instead of manually adding (aLineLeft, aBlockStart) when creating a shape,
add Translate() to let the shapes implement their only way to move their
origin. FloatInfo could then move the shapes after they're created.
MozReview-Commit-ID: ApZBHnkng74
--HG--
extra : rebase_source : 10da425372e4e26b0da506059befc99e1c47a39d
circle() allows the user to define an empty flow area, so IsEmpty() needs to
be overridden.
The flow area defined by a shape needs to be clipped to the margin-box per
https://drafts.csswg.org/css-shapes/#relation-to-box-model-and-float-behavior
In the reftests, both clip-path and shape-outside uses the same value so
that it's easier to debug visually.
Add LogicalPoint::LineRelative() because we need to convert a point's I() to
the line-axis in nsFloatManager. LineRelative() differs from I() in all
'rtl' direction per
https://drafts.csswg.org/css-writing-modes-3/#logical-to-physical
MozReview-Commit-ID: FxQaFPrEQ73
--HG--
extra : rebase_source : 0d768002a38adbded2a0caa6d3e001eaaca3313d
Create ShapeInfo as a base class for implementing all the shapes. In this
design, we only need to create the correct subclass in FloatInfo's
constructor whenever shape-outside is used rather than manually branching on
StyleShapeSourceType and StyleBasicShape in all the methods like
LineRight(), LineLeft(), etc.
The concrete subclass of ShapeInfo could focus on implementing how its shape
influence the flow area by overriding the needed methods in ShapeInfo.
Move ComputeEllipseLineInterceptDiff() and XInterceptAtY() under the scope
of ShapeInfo so that they could be used by BoxShapeInfo and all the other
ShpapeInfo subclasses yet to come.
MozReview-Commit-ID: ETVc5FdGNha
--HG--
extra : rebase_source : 9a083ccd95fd7565112a45e30c15a91b97c7290f
Use move constructor for two reasons. 1) The copy constructor is needed only
when appending FloatInfo to mFloats, so using move constructor will likely
be more efficient if some of the member variables support move constructor.
2) Part 6 will added a UniquePtr member to FloatInfo, so using move
constructor becomes necessary.
Also change the return value of AddFloat() to void to simplify the code,
since all the other callers do not check the return value, and
BlockReflowInput::FloatAndPlaceFloat() only asserts in debug mode. I assume
it's safe to omit the OOM check.
MozReview-Commit-ID: GVbbsdBjr7b
--HG--
extra : rebase_source : e0f647e029278a5033bb9d6d780e73e32de460d3
circle() allows the user to define an empty flow area, so IsEmpty() needs to
be overridden.
The flow area defined by a shape needs to be clipped to the margin-box per
https://drafts.csswg.org/css-shapes/#relation-to-box-model-and-float-behavior
In the reftests, both clip-path and shape-outside uses the same value so
that it's easier to debug visually.
Add LogicalPoint::LineRelative() because we need to convert a point's I() to
the line-axis in nsFloatManager. LineRelative() differs from I() in all
'rtl' direction per
https://drafts.csswg.org/css-writing-modes-3/#logical-to-physical
MozReview-Commit-ID: FxQaFPrEQ73
--HG--
extra : rebase_source : 0d768002a38adbded2a0caa6d3e001eaaca3313d
Create ShapeInfo as a base class for implementing all the shapes. In this
design, we only need to create the correct subclass in FloatInfo's
constructor whenever shape-outside is used rather than manually branching on
StyleShapeSourceType and StyleBasicShape in all the methods like
LineRight(), LineLeft(), etc.
The concrete subclass of ShapeInfo could focus on implementing how its shape
influence the flow area by overriding the needed methods in ShapeInfo.
Move ComputeEllipseLineInterceptDiff() and XInterceptAtY() under the scope
of ShapeInfo so that they could be used by BoxShapeInfo and all the other
ShpapeInfo subclasses yet to come.
MozReview-Commit-ID: ETVc5FdGNha
--HG--
extra : rebase_source : 9a083ccd95fd7565112a45e30c15a91b97c7290f
Use move constructor for two reasons. 1) The copy constructor is needed only
when appending FloatInfo to mFloats, so using move constructor will likely
be more efficient if some of the member variables support move constructor.
2) Part 6 will added a UniquePtr member to FloatInfo, so using move
constructor becomes necessary.
Also change the return value of AddFloat() to void to simplify the code,
since all the other callers do not check the return value, and
BlockReflowInput::FloatAndPlaceFloat() only asserts in debug mode. I assume
it's safe to omit the OOM check.
MozReview-Commit-ID: GVbbsdBjr7b
--HG--
extra : rebase_source : e0f647e029278a5033bb9d6d780e73e32de460d3
circle() allows the user to define an empty flow area, so IsEmpty() needs to
be overridden.
The flow area defined by a shape needs to be clipped to the margin-box per
https://drafts.csswg.org/css-shapes/#relation-to-box-model-and-float-behavior
In the reftests, both clip-path and shape-outside uses the same value so
that it's easier to debug visually.
Add LogicalPoint::LineRelative() because we need to convert a point's I() to
the line-axis in nsFloatManager. LineRelative() differs from I() in all
'rtl' direction per
https://drafts.csswg.org/css-writing-modes-3/#logical-to-physical
MozReview-Commit-ID: FxQaFPrEQ73
--HG--
extra : rebase_source : 02b4eafdff42477ef2c69d604a1650db01f954e4
Create ShapeInfo as a base class for implementing all the shapes. In this
design, we only need to create the correct subclass in FloatInfo's
constructor whenever shape-outside is used rather than manually branching on
StyleShapeSourceType and StyleBasicShape in all the methods like
LineRight(), LineLeft(), etc.
The concrete subclass of ShapeInfo could focus on implementing how its shape
influence the flow area by overriding the needed methods in ShapeInfo.
Move ComputeEllipseLineInterceptDiff() and XInterceptAtY() under the scope
nsFloatManager so that they could be used by BoxShapeInfo and all the other
ShpapeInfo subclasses yet to come.
MozReview-Commit-ID: ETVc5FdGNha
--HG--
extra : rebase_source : c73b0d0be2350db3eedb61b565de194842352ba1
Use move constructor for two reasons. 1) The copy constructor is needed only
when appending FloatInfo to mFloats, so using move constructor will likely
be more efficient if some of the member variables support move constructor.
2) Part 6 will added a UniquePtr member to FloatInfo, so using move
constructor becomes necessary.
Also change the return value of AddFloat() to void to simplify the code,
since all the other callers do not check the return value, and
BlockReflowInput::FloatAndPlaceFloat() only asserts in debug mode. I assume
it's safe to omit the OOM check.
MozReview-Commit-ID: GVbbsdBjr7b
--HG--
extra : rebase_source : 4765bbcf5c2533845bd8f7fb00117983429a622e
This patch is just renames. No logic change for the function.
MozReview-Commit-ID: K7w0YL3G3gu
--HG--
extra : rebase_source : d72ecdcb4d4455f4950c8673c81fbfc7c1b4f54c
The tests cases are designed based on the integer solution to the ellipse
equation (x/a)^2 + (y/b)^2 = 1, where x=36, y=32, a=60, b=40.
MozReview-Commit-ID: De2fXcb6ypP
--HG--
extra : rebase_source : a64f490ff41c020b84025266c0c255d93a158eea
In GetFlowArea(), "Shrink our band's height if needed." computation was
moved to the end because we need to pass the unmodified |blockEnd| to
compute LineRight() and LineLeft().
Revamp OutsetBorderRadii() to allow negative margin to reduce the radius,
but not below zero. Also implement the cubic formula required by the spec.
https://drafts.csswg.org/css-shapes/#valdef-shape-box-margin-box
OutsetBorderRadii() is now tailored only for margin-box with border-radius,
so it might no longer be suitable for other scenarios.
MozReview-Commit-ID: HKxW7rp6sIA
--HG--
extra : rebase_source : d416433016304feefc9ed9dcd1c22f7f2f92e27e
Per spec, float positioning and stacking is not affected by defining a float
area with a shape.
https://drafts.csswg.org/css-shapes/#relation-to-box-model-and-float-behavior
So all the call sites of GetFloatAvailableSpace() related to adding a
float are replaced by GetFloatAvailableSpaceForPlacingFloat().
<shape-box> with border-radius will be implemented in next part.
MozReview-Commit-ID: 1RXEeXDhdWo
--HG--
extra : rebase_source : 42cdb0c81b16168e4e30ee2261ceccb562e278cf
