1689989 - SVG elements become blurry when a transform attribute with a large scale value is updated rapidly

Status: RESOLVED DUPLICATE of bug 1878294

(Core :: Graphics: WebRender, defect, P3)

Description

[janne.ruoho]

Attachment: blur.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

Example 1: https://jsfiddle.net/xey9rfjv/
Use the slider to change how often the transform is updated (every 10-1000 ms)

Example 2: https://bl.ocks.org/puzzler10/91a6b53d4237c97752d0e466443dad0b
Zoom very close to the circles' edges

Actual results:

In example 1, when the transform is updated every ~ 10-400 ms, the circle is blurry. When the transform is updated less often, the circle is crisp.

In example 2, the circles are blurry when zoomed close to their edges, unless the zooming is performed very slowly one step at a time.

I was able to reproduce this behavior with:

• Firefox 85.0 on Windows 10
• Firefox 85.1.1 on Android 10

Expected results:

SVG elements should not become blurry when the transform attribute is updated rapidly.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Robert Longson [:longsonr]]

Seems very similar to bug 1688929 can you try disabling web render and confirm it doesn't happen? Do you get the same regression range as bug 1688929 comment 5?

Comment 3

[janne.ruoho]

Disabling WebRender does fix the blurring.

The regression range doesn't seem to be the same. Mozregression errored and stopped due to a missing build, but if I interpret it correctly, this is the range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=52285ea5e54c73d3ed824544cef2ee3f195f05e6&tochange=fa1da3c0b200abbd9cfab3cab19962824314044e

Bisecting on mozilla-central [2017-01-01 - 2018-01-29]
...
Tested mozilla-central build 2017-08-02 (verdict: g)
Tested mozilla-central build 2017-08-04 (verdict: b)
Tested mozilla-central build 2017-08-03 (verdict: b)

Comment 4

[Mayank Bansal]

With WR disabled, there is still some blurring, but it looks like "spikes" along the edge.

Comment 5

[Mayank Bansal]

Attachment: WR disabled

Comment 6

[janne.ruoho]

For me disabling WR made the edge just as perfect as the Chrome version in the first image.

Comment 7

[Timothy Nikkel (:tnikkel)]

(In reply to Robert Longson [:longsonr] from comment #2)

Seems very similar to bug 1688929 can you try disabling web render and confirm it doesn't happen? Do you get the same regression range as bug 1688929 comment 5?

We regressed and fixed the problem in bug 1688929 a few times IIRC from doing that bisection because we were still building some of the basic functionality into webrender. I only included the more recent regression range in my comment to the other bug. So that means the regression range one gets is dependant on the start dates and builds that mozregression chooses to test. However the range in comment 3 does not look familiar, so it might be distinct. There is https://hg.mozilla.org/mozilla-central/rev/a84cfe7de52c476bb5219ebffc3ed6d341dcb016 in there that is related to this kind of thing, but I'm not sure it was even used by webrender at that point in time.

Comment 8

[Timothy Nikkel (:tnikkel)]

Oh, also, you'd need to force webrender on using a pref to properly test.

Comment 9

[Timothy Nikkel (:tnikkel)]

Regression range for webrender forced on is bug 1415987.

The non-wr side is interesting too and might help fix this bug so I'll include what I found.

Similar to comment 3, when webrender is forced off I get this regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=52285ea5e54c73d3ed824544cef2ee3f195f05e6&tochange=63e261ce8cb04c913d2e6b19ea451b7078d24dc1

And the fix range when webrender is forced off
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2b2598fbd57c57b240eef1df930492ed7221029f&tochange=1256cc14812b94ec6988e64dd6e8e65504230853

-> bug 1634616

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 11

[Mayank Bansal]

FWIW, this was not fixed by bug 1804872

Comment 12

[Timothy Nikkel (:tnikkel)]

The patch in bug 1878294 should fix this.

I actually debugged this a while back, and then forgot to get a patch up, luckily bug 1878294 came around to remind me.

Comment 13

[Timothy Nikkel (:tnikkel)]

Should be fixed by bug 1878294 . Do you want to retest when the next nightly comes out?

Comment 14

[Mayank Bansal]

Attachment: Reporters_Standalone_testcase.html

Comment 15

[Mayank Bansal]

(In reply to Timothy Nikkel (:tnikkel) from comment #13)

Should be fixed by bug 1878294 . Do you want to retest when the next nightly comes out?

Testing this bug was already on my todo list :)

I can no longer repro this bug on the latest Nightly. It is fixed by bug 1878294. I will mark as dupe to reduce the number of tracking bugs, but feel free to change if you disagree.

Comment 16

[Timothy Nikkel (:tnikkel)]

Thanks!

FWIW, I used the testcase from this bug as the basis for a test since it was nice and simple.