Closed Bug 1287492 Opened 9 years ago Closed 8 years ago

Scaling past a certain point with a matrix transform in a SVG in combination with a CSS invert filter on the SVG prevents the SVG from being rendered at all.

Categories

(Core :: SVG, defect)

Product:
Core
Component:
SVG
Version:
47 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla54
Tracking Flags:
Tracking Status
firefox54 --- fixed

People

(Reporter: wiebe, Assigned: u459114)

References

Details

Attachments

(7 files, 1 obsolete file)

firefox-bug_svg-matrix-transform-and-css-invert-filter.html
2.67 KB, text/html
Details
Screenshot of how the test case renders incorrectly in Firefox
80.33 KB, image/png
Details
Screenshot of how the test case should render (in this case in Chrome).
119.26 KB, image/png
Details
Bug 1287492 - Part 1. Implement nsLayoutUtils::HasCSSBoxLayout.
59 bytes, text/x-review-board-request
mstange
: review+
Details
Bug 1287492 - Part 3. (Main) Shrink mTargetBBoxInFilterSpace
59 bytes, text/x-review-board-request
mstange
: review+
Details
Bug 1287492 - Part 4. Reftest
59 bytes, text/x-review-board-request
mstange
: review+
Details
Bug 1287492 - Part 2. Rewrite nsSVGUtils::GetNearestSVGViewport
59 bytes, text/x-review-board-request
mstange
: review+
Details
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160711192800 Steps to reproduce: I inserted a inline SVG in a HTML file with a SVG group element in it that has a matrix transform applied to zoom in. On the SVG element itself i have a CSS invert filter to invert all the colors (see the attached file that reproduces the problem). Actual results: When the matrix transform zooms in past a certain point the SVG is not rendered anymore, this only happens when the CSS invert filter is applied. Expected results: The SVG should be rendered no matter how far you zoom in and even when you apply the CSS invert filter.
Wiebe, could you attach a screenshot of the correct rendering of your entire testcase, please.
Flags: needinfo?(wiebe)
I have added a screenshot of how it renders in Firefox and breaks and one in Chrome where is does work.
Ty.
Flags: needinfo?(wiebe)
Assignee: nobody → cku
The patches in bug 1320036 can fix this bug too.
See Also: → 1320036
Attachment #8835365 - Attachment is obsolete: true
Attachment #8835379 - Flags: review?(mstange)
Attachment #8835501 - Flags: review?(mstange)
Attachment #8835380 - Flags: review?(mstange)
Attachment #8835440 - Flags: review?(mstange)
Although the patches in bug 1320036 can fix this bug as well, but the solution in that bug might be incorrect, depends on how we read spec[see bug 1320036 comment 23] The patches in this bug are not relative to bounding box computation.
Comment on attachment 8835379 [details] Bug 1287492 - Part 1. Implement nsLayoutUtils::HasCSSBoxLayout. https://reviewboard.mozilla.org/r/111064/#review112574
Attachment #8835379 - Flags: review?(mstange) → review+
Comment on attachment 8835380 [details] Bug 1287492 - Part 3. (Main) Shrink mTargetBBoxInFilterSpace https://reviewboard.mozilla.org/r/111066/#review112606 ::: layout/svg/nsFilterInstance.cpp:189 (Diff revision 5) > MOZ_ASSERT(mTargetFrame, "Need to supply a frame when there's no aOverrideBBox"); > mTargetBBox = nsSVGUtils::GetBBox(mTargetFrame); > } > > // Compute user space to filter space transforms. > - nsresult rv = ComputeUserSpaceToFilterSpaceScale(); > + if(!ComputeUserSpaceToFilterSpaceScale()) { missing space after "if"
Attachment #8835380 - Flags: review?(mstange) → review+
Comment on attachment 8835440 [details] Bug 1287492 - Part 4. Reftest https://reviewboard.mozilla.org/r/111182/#review112610
Attachment #8835440 - Flags: review?(mstange) → review+
Comment on attachment 8835501 [details] Bug 1287492 - Part 2. Rewrite nsSVGUtils::GetNearestSVGViewport https://reviewboard.mozilla.org/r/111234/#review112612
Attachment #8835501 - Flags: review?(mstange) → review+
It would be really nice to have the coordinates in the FilterDescription be independent of the filter resolution (for example in float user space pixels) and then convert to actual pixels only during painting, when we create FilterNodes from the FilterDescription (in FilterSupport). At that point we'd be able to look at the DrawTarget to know what resolution we should use for the intermediate surfaces and the FilterNode coordinate attributes.
Pushed by cku@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2dfa0badd7f4 Part 1. Implement nsLayoutUtils::HasCSSBoxLayout. r=mstange https://hg.mozilla.org/integration/autoland/rev/158d2fb726da Part 2. Rewrite nsSVGUtils::GetNearestSVGViewport r=mstange https://hg.mozilla.org/integration/autoland/rev/c8fd0f9baf34 Part 3. (Main) Shrink mTargetBBoxInFilterSpace r=mstange https://hg.mozilla.org/integration/autoland/rev/b209aadec564 Part 4. Reftest r=mstange
C.J., GetNearestSVGParent is really not a good name. It sounds like the function gets the "nearest parent in the SVG namespace" (any svg parent) whereas what it really does is get the "nearest viewport establishing SVG element's frame". Can you rename it back to GetNearestSVGViewport please?
Flags: needinfo?(cku)
Pushed by cku@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/1330b7dba04a (followup) Rename GetNearestSVGParent backto GetNearestSVGViewport. r=me
(In reply to Jonathan Watt [:jwatt] from comment #31) > C.J., GetNearestSVGParent is really not a good name. It sounds like the > function gets the "nearest parent in the SVG namespace" (any svg parent) > whereas what it really does is get the "nearest viewport establishing SVG > element's frame". Can you rename it back to GetNearestSVGViewport please? Sure and done
Flags: needinfo?(cku)
Depends on: 1348430
Depends on: 1349741
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: