1411693 - Google's search box shadow animation flickers/New tab shadows

Status: NEW

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

Description

[Darkspirit]

Attachment: testcase.html

Nightly 58 x64 20171025100449 de_DE @ Debian Testing (KDE, Radeon RX480)
fresh profile: gfx.webrender.enabled

See attached testcase + video.

The problem in bug 1411454 looks similar, but I couldn't make a testcase there (I'm a noob).
And it doesn't cases my UI to flicker like bug 1411131.

Comment 1

[Darkspirit]

Attachment: 2017-10-25_21-09-27.mp4

Comment 2

[Darkspirit]

correction:
> And it doesn't cause my UI to flicker like bug 1411131.

Comment 3

[Markus Stange [:mstange]]

I've filed https://github.com/servo/webrender/issues/1943 on this.

Comment 5

[Darkspirit]

Attachment: 2017-11-02_00-00-54.mp4

Nightly 58 x64 20171101104430 de_DE @ Debian Testing (KDE, Radeon RX480)
This has changed after the latest webrender update and got better.

fresh profile (left): layers force accel, webrender, blob-images
main profile (right): layers force accel, webrender, blob-images, omtp, gpu process, stylo-chrome

Only a white flickering is left.

Comment 7

[Ethan Lin[:ethlin]]

#1943 is fixed and I can't reproduce now. Can you confirm?

Comment 8

[Ethan Lin[:ethlin]]

(In reply to Ethan Lin[:ethlin] from comment #7)
> #1943 is fixed and I can't reproduce now. Can you confirm?

Oh..#1943 is still open. But I can't reproduce the problem on windows and macOS.

Comment 9

[Darkspirit]

Attachment: 2017-12-21_03-41-58.mp4

100% zoom and some other zoom levels show the problem, some other not.

Comment 10

[Peter Chang[:pchang]]

I can't reproduce this with latest nightly on OSX and window. Checking this on linux now.

Comment 11

[Peter Chang[:pchang]]

Can't reproduce this on linux as well.

Reporter, can you help to confirm it?

Comment 12

[Darkspirit]

Nightly 59 x64 20180115100056 de_DE @ Debian Testing (KDE, Radeon RX480)
fresh profile: gfx.webrender.all

I can still reproduce on Linux and will check this on Windows 10.

Comment 13

[Milan Sreckovic [:milan] (needinfo for best results)]

There are enough artifacts that we can't really close any of the "flickering" bugs as "works for me".  And it sounds like :darkspirit can reproduce it anyway.

Peter, do have have discrete graphics?  I find for me it happens a lot more on Nvidia than on Intel.

Comment 14

[Peter Chang[:pchang]]

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #12)
> Nightly 59 x64 20180115100056 de_DE @ Debian Testing (KDE, Radeon RX480)
> fresh profile: gfx.webrender.all
> 
> I can still reproduce on Linux and will check this on Windows 10.

:darkspirit Do you have the chance to verify this on windows 10?

Comment 15

[Darkspirit]

Attachment: 2018-01-17 03-59-36_20180116220110_Win10.mp4

Nightly 59 x64 20180116220110 de_DE @ Windows 10 (Radeon RX480)
fresh profile: gfx.webrender.all
Still reproducible.

Comment 16

[Peter Chang[:pchang]]

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #15)
> Created attachment 8943102 [details]
> 2018-01-17 03-59-36_20180116220110_Win10.mp4
> 
> Nightly 59 x64 20180116220110 de_DE @ Windows 10 (Radeon RX480)
> fresh profile: gfx.webrender.all
> Still reproducible.

Thanks.


I also modified the test case a little bit to make it more obvious to see.
http://jsfiddle.net/efvyw2eq/

Now I can reproduce this on linux(nvidia) and windows(nvidia) but not OSX.

Comment 17

[Darkspirit]

Attachment: testcase2.html

Pimped testcase from comment 16.

Comment 18

[Darkspirit]

try builds from bug 1440664:
> WR @ 4e374f0c5139ca81ee8de99afe2fc3bc53e3632e
mozregression --repo try --launch 3894fc62b9052a377b1e0a0287f44722751fbb4d --pref gfx.webrender.all:true startup.homepage_welcome_url:"https://bugzilla.mozilla.org/attachment.cgi?id=8922041"
bad

> WR @ b53cf7799a0f5861dfa928ee0ccc66e8d0b78758
mozregression --repo try --launch d115c4c11850c1b1d0b1c847eefc3d959efe0b12 --pref gfx.webrender.all:true startup.homepage_welcome_url:"https://bugzilla.mozilla.org/attachment.cgi?id=8922041"
good

Fix range: https://github.com/servo/webrender/compare/4e374f0c5139ca81ee8de99afe2fc3bc53e3632e...b53cf7799a0f5861dfa928ee0ccc66e8d0b78758

This got far better, but is not fixed. attachment 8957846 [details] shows the remaining problem more clearly.

Comment 19

[Darkspirit]

Attachment: 2018-03-10_22-59-42.mp4

attachment 8957846 [details]: ESR vs. WR

Comment 20

[Aria Beingessner [:Gankra]]

Lowering the priority on this since the severity has reduced. On google itself I can't actually notice anything, though I do see the issue clearly on Jan's testcase2

Comment 21

[Darkspirit]

I think the borders of hovered tiles on about:newtab have the same problem.

Comment 22

[Darkspirit]

I still see a wiggling shadow on Google.

Testcase from bug 1468047 comment 3: attachment 8984725 [details]

Comment 24

[Aria Beingessner [:Gankra]]

This is such a minor rendering quality of implementation issue that I think we can ship without fixing this. And it shouldn't cause a major rearchitecting to fix when we do get to it.

Comment 25

[Darkspirit]

The shadow of the thumbnails on the right: https://www.servoexperiments.com/experiments/divMosaics/

Comment 27

[Alex Thayer [:alexical] (she/her)]

This is pretty minor in many cases, but it's quite noticeable and likely to be encountered very frequently in the Top Sites section of Activity Stream. We should either fix it here or get the Activity Stream folks to change how they animate Top Sites hovering.

Comment 28

[Jeff Muizelaar [:jrmuizel]]

Nical, it looks like this is similar to bug 1475827 and may have the same root cause. Let me know if you feel otherwise.

Comment 29

[Nicolas Silva [:nical]]

Sounds plausible.

Comment 30

[Glenn Watson [:gw]]

A slightly simplified test case, without animation to ease debugging:

box-shadow: 0px 0 1.5px 0 rgba(0,0,0,1);

With layout.css.devPixelsPerPx set to 1 looks fine without WR, but is asymmetrical with WR.

Comment 31

[Glenn Watson [:gw]]

I can see at least one problem here - the prim_shadow_rect is not rounded, and thus it can result in an asymmetrical stretch occurring during the clip mask generation.

I put up a try run with a hack fix for that here - https://treeherder.mozilla.org/#/jobs?repo=try&revision=7f4c4eb820df368d9606469fc6dd63b5dabb0add

It's still not perfect, but anecdotally it seems significantly better to me on the test cases in this bug and https://bugzilla.mozilla.org/show_bug.cgi?id=1475827.

The lack of rounding in the prim_shadow_rect is definitely an issue, but I'm not 100% certain whether (a) this is a good fix (and there is another bug causing the remaining issues) or (b) this fix isn't sufficient and can break / not fix some cases.

I'll see what breaks on the try run and do a more detailed investigation tomorrow.

Comment 32

[Glenn Watson [:gw]]

The try run above isn't quite finished, but it looks like it makes boxshadow-large-border-radius.html and boxshadow-skiprect.html pass. There also doesn't like like there are any new failures (just a couple of already known intermittents).

So I'll open a patch for this tomorrow, and then we can see if it resolves this issue completely, or needs some additional fixes.

Comment 33

[Darkspirit]

Attachment: 2019-01-23 14-34-40.mp4

Win10, GTX1060

left (WR): mozregression --launch 2019-01-23 --pref gfx.webrender.all:true -a https://bug1411693.bmoattachments.org/attachment.cgi?id=8957846 -a https://bugzilla.mozilla.org/attachment.cgi?id=8984725 -a https://www.servoexperiments.com/experiments/divMosaics/

middle (WR try): mozregression --repo try --launch 7f4c4eb820df368d9606469fc6dd63b5dabb0add --pref gfx.webrender.all:true -a https://bug1411693.bmoattachments.org/attachment.cgi?id=8957846 -a https://bugzilla.mozilla.org/attachment.cgi?id=8984725 -a https://www.servoexperiments.com/experiments/divMosaics/

right (non-WR): mozregression --launch 2019-01-23 --pref gfx.webrender.force-disabled:true -a https://bug1411693.bmoattachments.org/attachment.cgi?id=8957846 -a https://bugzilla.mozilla.org/attachment.cgi?id=8984725 -a https://www.servoexperiments.com/experiments/divMosaics/

It's a vast improvement (thank you!), although not smooth on servoexperiments.com.

Comment 34

[Glenn Watson [:gw]]

https://bugzilla.mozilla.org/show_bug.cgi?id=1522351 is the patch that includes the partial fix above.

Comment 36

[Jeff Muizelaar [:jrmuizel]]

Dropping back down to P3 because bug 1522351 has been fixed

Comment 37

[Glenn Watson [:gw]]

I think that this is fixed once https://bugzilla.mozilla.org/show_bug.cgi?id=1523882 lands in a nightly (or at least improved enough to be shippable). darkspirit, could you confirm?

Comment 38

[Darkspirit]

Attachment: 2019-02-02 21-38-28.mp4

Still flickering shadow: https://bug1490883.bmoattachments.org/attachment.cgi?id=9008602
Shadows should smoothly fade in: https://www.servoexperiments.com/experiments/divMosaics/

Comment 39

[Glenn Watson [:gw]]

I can see the flickering sometimes on the test case if I set layout.css.devPixelsPerPx to 1, but I don't see it at the default for my screen. I suspect this might be related to fractional values being rounded.

Similarly for the mosaics case, it doesn't appear to be smooth, but if I alter the box shadow blur in devtools from 5px to 15px, it looks smooth on my machine. This also suggests that the issue might be related to fractional values being rounded.

Comment 40

[Glenn Watson [:gw]]

Nical, do you have cycles to do some more investigation of this?

Comment 41

[Nicolas Silva [:nical]]

Right now I am focusing on bug 1523495 so this one is free to be picked up by anyone with an empty p2/p3 list. That said, there is a small chance that two bugs are actually affected by the same root issue.

Bug 1523495 is also related to the "intensity" of blurs incorrectly varying depending on a parameter that shouldn't affect it. My current theory is that we use linear filtering during down-scale in srgb space which doesn't preserve the perceptual intensity of the color/alpha, so depending on the sizes of the input/output targets during down-scaling sampling will play out differently and lead to different blur intensities.

I haven't verified whether this is what's happening here as well but some of the symptoms described in this bug match what I am observing in the other bug.

Comment 42

[Glenn Watson [:gw]]

The test case from https://bugzilla.mozilla.org/show_bug.cgi?id=1411693#c30 is now working correctly, as a result of https://bugzilla.mozilla.org/show_bug.cgi?id=1523882 (the box shadow is symmetrical).

However, it's still not smooth in testcase2.html. I can reproduce the smoothness issue even with the blur radius set to 0. It looks like the AA is taking effect on the inner edge of the shadow, which might be what's causing the perceived flickering. This might be related to snapping - still investigating.

Comment 43

[Jeff Muizelaar [:jrmuizel]]

I'm moving this to P4. If anyone has a prominent web property whether this is still quite bad we can consider moving it back up in priority.

Comment 44

[Glenn Watson [:gw]]

I wonder if this is still an issue after Andrew's snapping changes landed?

Comment 45

[Andrew Osmond [:aosmond] (he/him)]

I don't think https://www.servoexperiments.com/experiments/divMosaics/ has improved at all before or after my change. I can see the transition is smooth on Chrome for me.

Comment 46

[Jeff Muizelaar [:jrmuizel]]

Yeah, testcase2.html is still smoother in Chrome.

Comment 47

[Glenn Watson [:gw]]

Un-assigning for now, since I'm not intending to work on this in the near future - we have it tagged as part of wr-snap.

Comment 48

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

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates.
:gw, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 49

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.