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.

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

Sounds plausible.

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.

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.

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.

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.

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

Dropping back down to P3 because bug 1522351 has been fixed

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?

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

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.

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

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.

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.

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.

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

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.

Yeah, testcase2.html is still smoother in Chrome.

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.

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.

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.