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.

RESOLVED FIXED in Firefox 54

Status

()

RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: wiebe, Assigned: u459114)

Tracking

47 Branch
mozilla54
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox54 fixed)

Details

Attachments

(7 attachments, 1 obsolete attachment)

(Reporter)

Description

2 years ago
Created attachment 8772023 [details]
firefox-bug_svg-matrix-transform-and-css-invert-filter.html

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.
Component: Untriaged → SVG
Product: Firefox → Core

Comment 1

2 years ago
Wiebe, could you attach a screenshot of the correct rendering of your entire testcase, please.
Flags: needinfo?(wiebe)
(Reporter)

Comment 2

2 years ago
Created attachment 8773409 [details]
Screenshot of how the test case renders incorrectly in Firefox
(Reporter)

Comment 3

2 years ago
Created attachment 8773410 [details]
Screenshot of how the test case should render (in this case in Chrome).
(Reporter)

Comment 4

2 years ago
I have added a screenshot of how it renders in Firefox and breaks and one in Chrome where is does work.

Comment 5

2 years ago
Ty.
Flags: needinfo?(wiebe)
(Assignee)

Updated

2 years ago
Assignee: nobody → cku
(Assignee)

Comment 6

2 years ago
The patches in bug 1320036 can fix this bug too.
(Assignee)

Updated

2 years ago
See Also: → bug 1320036
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
(Assignee)

Updated

2 years ago
Attachment #8835365 - Attachment is obsolete: true
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
(Assignee)

Updated

2 years ago
Attachment #8835379 - Flags: review?(mstange)
Attachment #8835501 - Flags: review?(mstange)
Attachment #8835380 - Flags: review?(mstange)
Attachment #8835440 - Flags: review?(mstange)
Comment hidden (typo)
(Assignee)

Comment 19

2 years ago
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 hidden (mozreview-request)
Comment hidden (mozreview-request)

Comment 22

2 years ago
mozreview-review
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 23

2 years ago
mozreview-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 24

2 years ago
mozreview-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 25

2 years ago
mozreview-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.
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)

Comment 29

2 years ago
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

Comment 30

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/2dfa0badd7f4
https://hg.mozilla.org/mozilla-central/rev/158d2fb726da
https://hg.mozilla.org/mozilla-central/rev/c8fd0f9baf34
https://hg.mozilla.org/mozilla-central/rev/b209aadec564
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
status-firefox54: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
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)

Comment 32

2 years ago
Pushed by cku@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1330b7dba04a
(followup) Rename GetNearestSVGParent backto GetNearestSVGViewport. r=me
(Assignee)

Comment 33

2 years ago
(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)
(Assignee)

Updated

2 years ago
Depends on: 1348430
(Assignee)

Updated

2 years ago
Depends on: 1349741
You need to log in before you can comment on or make changes to this bug.