filter-in-pattern-02.svg/filter-in-pattern-02-ref.svg
The only difference between 02 and 02-ref is filter effects region setting. The
effect region of 02 is (x=-1 y=-1 w=10 h=10), while the region of 02-ref
is (x=0 y=0 w=9 h=9). Supposedly, the rendering result of 02 and 02-ref should
not be the same. But since we clip effects region by viewporit in
ComputeTargetBBoxInFilterSpace, 02 look almost the same with 02-ref whithout
Part 3.
MozReview-Commit-ID: cqMGqGuHL0
--HG--
extra : rebase_source : 416b8378d384fd12638ee73c479ddf2254bdfb45
I introduced ComputeTargetBBoxInFilterSpace[1] function in bug 1287492.
Two reasons that I think we should not clip filter boundary by viewport
in that function:
1. The patch in bug 1336480 can also fix bug 1287492 and is more correct.
2. That restriction cause wrong rendering result
In this bug, reporter apply filter onto a path object in pattern element.
Before the clipping applied in [1], the boundary of filter effects region is
(x=-1, y=-1, width=10, height=10) in CSS units
After clipping by svg viewport, the boundary turns out to be
(x=0, y=0, width=9, height=9) in CSS units
which is smaller then we need for filter painting. So we should stop clip the
boundary by svg viewport. (Please refer to filter-in-pattern-02.svg in the next
patch).
[1] https://hg.mozilla.org/mozilla-central/file/dbabc189256e/layout/svg/nsFilterInstance.cpp#l235
MozReview-Commit-ID: 2d14rnyWPJs
--HG--
extra : rebase_source : ca3a523c8ae95d166441690d5ee1def2ed56a550
There are two places that use nsFilterInstance::PaintFilteredFrame. One is
nsSVGIntegrationUtil::PaintFilter, we do take care of it in bug 1224207.
Another path is at nsSVGUtils::PaintFrameWithEffects, apparently I missed that
path while working on bug 1224207.
MozReview-Commit-ID: K4MjKa4ZpCR
--HG--
extra : rebase_source : 46696b620b210348052fe554b15abf0c3adedc72
This is a bug from https://hg.mozilla.org/mozilla-central/rev/2d171d75b746 (bug 1157546). It took a shortcut in trying to get around one of the downsides of tracking visibility on frames instead of content nodes.
We cannot get our primary frame during FrameCreate calls because FrameCreate is called during the frame's Init() function, which happens before the primary frame pointer is set.
So when TrackImage is called from FrameCreate |frame| will be null but mFrameCreateCalled will be true. So we won't hit the early return that tries to detect nonvisible images.
The comment being removed is just wrong. We can obtain a frame for <feImage> just as well as any other image type.
The thing that is different about <feImage> is that it calls IncApproximateVisibleCount() followed by FrameCreated() in the frame's Init() function. This means that the frame is marked visible at the time of the FrameCreated, and there will be no further calls to TrackImage (because there are no further changes). So the FrameCreated call is the last chance to mark this image visible. The regressing changeset tries to get around this by just considering the image visible whenever we know a frame exists (because of mFrameCreateCalled) but can't access it. This ends up affecting all types of images, not just <feImage>.
The above paragraph is also true for SVG <image> that are non-display.
Currently, stylo doesn't have css-color-4 implementation. Set expected-fail for these tests.
--HG--
extra : rebase_source : 7740e267deed0482a25289704868cadd30e35e0f
nsStyleContext::CalcDifference had an optimization where, when we knew
that the old and new style context have the same rule node, we knew that
the only change hints that would need to be handled are those in the
"not handled for descendants" category, generated due to explicit
'inherit' values on reset properties. This was because any changes due
to differences in inherited properties should only have generated
"handled for descendants" change hints (and thus would already have been
handled on an ancestor).
Before bug 931668, this let us avoid calling CalcDifference on structs
that only would have generated hints that we knew we already would have
handled. However, after bug 931668, we compare all structs anyway so
that we can set the aEqualStructs outparam, so we don't gain anything
from this optimization. We can still return these change hints we know
will not need to be handled, and rely on ElementRestyler::CaptureChange
to filter them out.
MozReview-Commit-ID: Ld1s2Js0i6r
This changes ElementRestyler::CaptureChange so that it avoids generating the
current frame's entire set of change hints, if only some of the hints were
handled by ancestors, and instead to remove the hints that we know are
subsumed.
MozReview-Commit-ID: JvhxeQC6MmQ
The relevant frame classes are:
SubDocumentFrame
ListControlFrame (only when used for (non-e10s?) comboboxes)
PluginFrame
ViewportFrame
MenuPopupFrame
The view is now created in the frame's Init() method, except for
ViewportFrame which has its view assigned by the frame constructor
via a SetView() call.
MozReview-Commit-ID: 4O7Hm1yqwIp
Views are used for PluginFrame which inherits nsFrame, not nsContainerFrame,
so it's more appropriate that these methods should live in nsIFrame/nsFrame.
MozReview-Commit-ID: 87EgCnkF5YT
sutagent is no longer built or used; devicemanagerSUT is completely
unused. After this change, devicemanagerADB is the only implementation of
devicemanager, and test harness options like --dm_trans are eliminated.
This function is not a virtual function and always returns CAIRO_STATUS_SUCCESS
after the patch in bug 1054838 landed. There is no reason to keep it anymore.
MozReview-Commit-ID: EadrrFQyjfY
--HG--
extra : rebase_source : 3f6a284dc9fa396d5cfd3f64190562373801a0a2
We use Servo css-parser to parse keyframe property-value pairs, so we
should also use it to parse easing for Web Animations.
MozReview-Commit-ID: FsfHQaNT2xO
--HG--
extra : rebase_source : 8eb6489f257839f2c0de943b63cc1c04b44ff7a5
cku
Carsten "Tomcat" Book
Emilio Cobos Álvarez
Iris Hsiao
Jonathan Watt
Timothy Nikkel
Wes Kocher
JerryShih
Cameron McCormack
Mats Palmgren
Sebastian Hengst
Boris Zbarsky
Geoff Brown
Boris Chiou