These tests no longer assert so we can remove the stylo annotations.
MozReview-Commit-ID: 7sWWTkoFp1G
--HG--
extra : rebase_source : e42f418ef1756a08bc0f11b02b42b2a1737deb76
All classes which have mCanvasTM declared as a member object are inherited from
nsSVGDisplayContainerFrame. We should just declare a protected member in the
base class and then remove mCanvasTM and duplicated implementaion of
GetCanvasTM & NotifySVGChanged in those derived classes.
MozReview-Commit-ID: 8f8EgFNEXHJ
--HG--
extra : rebase_source : 593e16d7b701061ca37b8ca8a6fe1de2292ea62d
In nsSVGUtils::GetBBox, we cache fill-gemorty's bbox in ObjectBoundingBoxProperty
of the given frame[1] so that we can just return the cache value without
recomputing bbox. Some new added flags, such as eUseFrameBoundsForOuterSVG,
prevent storing and reusing this cache value. This patch is trying to make this
cache mechanism work again.
[1]
https://hg.mozilla.org/mozilla-central/file/ef585ac7c476/layout/svg/nsSVGUtils.cpp#l1119
MozReview-Commit-ID: 8vWDzFi8qCw
--HG--
extra : rebase_source : 07725c856f77f95717f16e61a9838393b09f5789
When nsSVGUtils::getBBox is called on <use> element:
1. Call from SVGGraphicsElement::getBBox(WebAPI):
According to the spec, getBBox should return the bbox as the union box of
children in user space.
2. Call from mask/ clip-path or filter painting:
Since we want to paint those elements in the coordinate space formed by
<use>(bug 537623), getBBox should return the bbox as the union box of
children in coordinate system of <use>.
Depend on the use case, we return the bbox of an <use> element on different
coordinate system. In this patch, I bring in a new
flag(eInUserSpaceOfUseElement) so that nsSVGUtils::getBBox can return bbox on
different coordinate system accordingly.
MozReview-Commit-ID: FfZalTI8J0y
--HG--
extra : rebase_source : c33e980c00c450792b30f60f6aa01b53e1c5595c
The failure mode in the attached crashtest is an inconsistency in the flattened
tree. Specifically, we null out mVideoControls in an nsVideoFrame, but defer
the UnbindFromTree call on that NAC element, which measn that its mParent still
points to the nsVideoFrame's mContent. Because all this stuff runs off of script
runners, and the anonymous content destroyer is not guaranteed to run before
other potential script runners, we end up running arbitrary script while the
tree mismatch exists. This script calls back into ProcessPendingRestyles, which
causes trouble.
We could build a separate deferral mechanism, but it's not clear that we actually
need to defer the unbind anymore. The deferred unbind was added in bug 489008,
which predated a lot of simplifications in layout/dom interaction.
MozReview-Commit-ID: 1JYAhiXKVJC
This patch has no direct relation with this bug. When tracing the code, I noticed
those local nsSVGLength2 variables can be declared as const reference.
MozReview-Commit-ID: 6gkdlpv8W7H
--HG--
extra : rebase_source : 0b875b0a375e9254eec3d1c569274fae8edfdcfe
There are two overloads of nsSVGLength2::GetAnimValue:
1. float nsSVGLength2::GetAnimValue(nsSVGElement*) const;
2. float nsSVGLength2::GetAnimValue(SVGSVGElement*) const;
In Bug 265894, I created SVGViewportElement as a base class of SVGSVGElement.
SVGSVGElement::GetViewBoxTransform was moved to SVGViewportElement in that
refactoring. The local variable 'ctx' in that function was changed from
SVGSVGElement to SVGViewportElement, which when passed to
nsSVGLength2::GetAnimValue caused us to switch from calling the overload that
takes a SVGSVGElement to the overload that takes a nsSVGElement, which is not
what we want.
This patch changes the argument type of the nsSVGLength2::GetAnimValue overload
that takes an SVGSVGElement to take an SVGViewportElement instead, which causes
the GetAnimValue(ctx) calls in SVGViewportElement::GetViewBoxTransform to call
the correct GetAnimValue overload again.
MozReview-Commit-ID: 2cmgIoltYfY
--HG--
extra : rebase_source : b45282cc492cf067ecc3935b03cde243a69ef2b5
In while-loop [1],
1. The first SetMatrix call that I remvoed in this patch is totally useless,
we can just pass initialMatrix to contextPaint, instead of set initialMatrix
to aContenxt and read back from aContext and then pass it to contextPaint.
2. This function, SVGTextFrame::PaintSVG, is the only caller of
SetupStrokeGeometry, and it does not need SetupStrokeGeometry to setup matrix at
all, since it will be overwritten the transform matrix of aContext at several
lines below[2].
[1]
https://hg.mozilla.org/mozilla-central/file/5115e2dea29a/layout/svg/SVGTextFrame.cpp#l3658
[2]
https://hg.mozilla.org/mozilla-central/file/5115e2dea29a/layout/svg/SVGTextFrame.cpp#l3685
MozReview-Commit-ID: AlKQh4abbpa
--HG--
extra : rebase_source : e0dfd66ff25be0d7cffadecf9e3333bba10cff9b
(This patch is not relative to performance)
Rename this function since it has not relation with cario at all.
MozReview-Commit-ID: DHvrsVZAJ7B
--HG--
extra : rebase_source : 4994c9058bd93c7d6671e57ce7f204185e679a1a
Unless we need to draw stroke of glyphs, which will change the state of the
target context, we only need to save & restore transform matrix of the target
context.
MozReview-Commit-ID: LLKnxrKrDaT
--HG--
extra : rebase_source : 1226c48d283a04cb0ea6959f12fd6938fece49d2
nsDisplaySVGText::Paint calls SVGTextFrame::PaintSVG, and we already save/restore
context state in SVGTextFrame::PaintSVG.
I also filed Bug 1385929 to find a solution to prevent duplicated
gfxContext::Save/Restore.
MozReview-Commit-ID: 4WxdFZzvmvF
--HG--
extra : rebase_source : 752d5d027776538edc1ab043ad2e90e1de22a079
I've been having problems with interdiffs on mozreview lately, so for
ease of review, this patch is being submitted as a seperate patch for
review. Once it is r+'d, it will be folded into the first patch in
this set before landing.
MozReview-Commit-ID: CS9MngaXlBd
--HG--
extra : rebase_source : 6a86fd4f7a66e73497a756976a2562d183002a2a
nscoord_MAX is (1<<30) so that we can check for overflow *after* adding
two nscoords. However, (nscoord_MAX + nscoord_MAX) will still overflow.
Subtracting one makes this no longer possible.
MozReview-Commit-ID: BtbQRMp5kWm
nscoord_MAX is (1<<30) so that we can check for overflow *after* adding
two nscoords. However, (nscoord_MAX + nscoord_MAX) will still overflow.
Subtracting one makes this no longer possible.
MozReview-Commit-ID: BtbQRMp5kWm
One thing to note here is that the Scale function on gfxRect has a
different implementation than that in gfx::Rect which is replacing it.
The former just scales the width/height directly whereas the latter
scales the XMost/YMost and recomputes the width/height.
MozReview-Commit-ID: 5FImdIaNfC3
--HG--
extra : rebase_source : 98662d2a52ff9652ec60b066641a07c6d5ee8e08
Most of this patch is updating a few places that use gfxMatrix to use
the equivalent-but-differently-named functions on MatrixDouble:
- Translate/Rotate/Scale get turned into PreTranslate/PreRotate/PreScale
- Transform(Point) gets turned into TransformPoint(Point)
- gfxMatrix::TransformBounds(gfxRect) gets turned into
gfxRect::TransformBoundsBy(gfxMatrix).
- gfxMatrix::Transform(gfxRect) gets turned into
gfxRect::TransformBy(gfxMatrix).
The last two functions are added in this patch as convenience wrappers
to gfxRect instead of Matrix.h because we don't want Matrix.h to "know"
about gfxRect (to avoid adding gecko dependencies on Moz2D). Once we
turn gfxRect into a typedef for RectDouble these will be eliminated
anyway.
MozReview-Commit-ID: BnOjHzmOSKn
--HG--
extra : rebase_source : cf1692d1f0d44a4b05d684a66678739181a426d5
This extracts a BaseMatrix template of which Matrix is now a particular
specialization. The BaseMatrix allows us to reuse the same code for
floats and doubles, much like the other "base" classes (BasePoint,
BaseRect, etc.).
MozReview-Commit-ID: HO7bA83S9E0
--HG--
extra : rebase_source : dcd84d9a978cdea00bb54eb11eefcca9c6635901
Most of the changes in this patch are just using the explicit
constructor from gfx::IntSize to gfx::Size, since gfxSize did
that implicitly but gfx::Size doesn't.
MozReview-Commit-ID: CzikGjHEXje
--HG--
extra : rebase_source : 9d19977f2a774d9a2a653db923553a6c2e06f82a
