User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

Set
gfx.webrender.all = true
gfx.webrender.software = true

Restart FF.
Open Hamburger Menu

Actual results:

Black Box around menu instead of shadow

Expected results:

Floating shadow below menu

Andrew and/or Martin, I see this on Linux even if I use HW WR. This does not appear to be a SW WR bug at all, but something perhaps related to windowing and WR in general on Linux?

This may be:

• a duplicate / incarnation of Bug 1663003 (different GL/X visual)
• we don't use ARGB visual for the popup, it may be a misconfiguration at nsWindow::Create(), we perhaps don't handle WebRender with non-GL backend
• you have compositing disabled on OS and we don't use shapes for GL - Bug 1479135.

A patch from Bug 1663273 may help also here.

(In reply to Lee Salzman [:lsalzman] from comment #1)

Andrew and/or Martin, I see this on Linux even if I use HW WR. This does not appear to be a SW WR bug at all, but something perhaps related to windowing and WR in general on Linux?

Just to be clear this does not happen to me if only Webrender is enabled. ( gfx.webrender.all = true)

Thanks for the report!

Gnome X11 (with KDE theme), Debian Testing, GTX1060, proprietary driver 450.80.02
If you look at the screenshot in comment 0, the bottom left corner is round, it's just shadow over shadow over shadow.
I can reproduce this by moving my mouse up and down on the main menu. It does not occur with HW WR.

mozregression --launch 20201116094341 --pref gfx.webrender.all:true gfx.webrender.software:true

Lee, I understand what happens there, I was mistaken by the picture. When you draw a transparent window on Linux you always need to clear the back buffer before you paint the transparent widget. What you see here are blended shadows painted over and over. It's because we have disabled window background rendering so Gtk does not clear widget background for us.

(In reply to Martin Stránský [:stransky] from comment #7)

Lee, I understand what happens there, I was mistaken by the picture. When you draw a transparent window on Linux you always need to clear the back buffer before you paint the transparent widget. What you see here are blended shadows painted over and over. It's because we have disabled window background rendering so Gtk does not clear widget background for us.

So is this a bug that is occurring and must be fixed somewhere in the widget code, or is it higher up in WebRender itself?

bull500, is this bug still occurring for you?

Or Darkspirit, can you reproduce?

I am not sure I am seeing it anymore locally for myself, so maybe bug 1663003 fixed it?

Still reproducible on Gnome XWayland, Debian Testing, Intel:
mozregression --launch 2020-12-15 --pref gfx.webrender.all:true gfx.webrender.software:true

bug 1479135 comment 55 switched shaped popups on non-composited desktops (KDE without compositing, i3) from WR to Basic/Skia, instead of properly fixing it. I think you can't reproduce it anymore because you are not using sw-wr for shaped popups anymore.
This also caused a sessionrestore regression for sw-wr: bug 1681047

This shadow-over-shadow-over-shadow bug occurs only on composited desktops.
I would naively raise the question whether UseSoftwareWebRender should be checked somewhere so that at least the SW-WR codepath keeps using SW-WR for popups.

On non-composited desktops, the popup's nontransparent shadow was plain black with hw and sw WR - before bug 1479135 comment 55 switched popups to Basic.
bug 1479135 was originally about using XShape not only for Basic, but also for WR. This still needs to be done or a different solution be found that doesn't involve using Basic.
Could SWWR take the same code path as Basic and also use X11's XShape to entirely cut off the non-transparent shadow on non-composited desktops?

Could SWWR take the same code path as Basic and also use X11's XShape to entirely cut off the non-transparent shadow on non-composited desktops?

IIUC the xshape code would need to live in WR/rustland for both hardware and software WR. SWWR apparently doesn't share more codepaths with basic than WR does. Which is, IIUC, one of the main reasons SWWR exists in the first place.

I see, yes. This is X11 bug only (at least I can reproduce it on X11 only) and it's caused by missing widget background. I'll look at it along Bug 1679215 which is related.

I think WebRender uses a wrong painting operation to SW buffer here.

Looks like alpha blending is used instead of just repaint (pixel replace) of the damaged areas. I'm not sure which alpha blending operation is used but affects only semi-transparent pixels. I think when partial update is performed, the pixels should be just replaced without alpha blending and the alpha channel value needs to be copied to target surface and not used for painting.

This bug affects both Wayland/X11 backends but Wayland has a workaround for it which causes the Bug 1679215 (widget code considers partial updates as a full window updates and clears the surface to avoid this bug).

Martin and bull500, did the fixes in bug 1679215 improve this at all?

(In reply to Lee Salzman [:lsalzman] from comment #17)

Martin and bull500, did the fixes in bug 1679215 improve this at all?

I tested that build. Wayland flickering seems to be partially fixed (I see some artifacts in popup menu) but the borders behaves the same way on X11 and Wayland, i.e. are more and more visible how the widget is repainted.

Lee, I suggest to fix X11 backend first and then focus to Wayland. I can update Wayland backend according to the X11 one.

(In reply to Martin Stránský [:stransky] from comment #19)

Lee, I suggest to fix X11 backend first and then focus to Wayland. I can update Wayland backend according to the X11 one.

I suspect this is a bug in the widget code based on your description. WR itself has no notion of alpha-blending the main framebuffer and rather just overwrites everything in the invalidation region for the current frame. The X11 backend also has no notion of blending the framebuffer either, since X11 does not support this, so I guess I am somewhat confused as to what is going on? I would appreciate if you would either further elaborate on what's going on or write up a patch to improve the situation.

Okay, I logged some frames with Bug 1686341 and the buffers looks sane. But I'm confused why it affects X11 code too...will look at it anyway, seems to be a bug in widget code.

Clear alpha from buffer before painting transparent windows by SW Webrender to avoid rendering atrifacts.

Depends on D102189

Use gfx::DataSourceSurface instead of gfxImageSurface to cache drawing and don't use blending
when we paint cached images to Wayland buffer.

Depends on D102190

https://hg.mozilla.org/mozilla-central/rev/7ac989d08efb
https://hg.mozilla.org/mozilla-central/rev/6551851d5014
https://hg.mozilla.org/mozilla-central/rev/58ed4dcf4307

https://hg.mozilla.org/mozilla-central/rev/3ab89af2c93d