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

Steps to reproduce:

1. set gfx.webrender.max-partial-present-rects to a value other than 0
2. restart browser
3. view a webm video

Actual results:

Video didn't look right, portions of it never updated after being rendered

Expected results:

Video playback was normal

Some additional info:
Compositor: Mutter 3.36.2 in wayland mode
GPU: AMD Radeon Rx580 with opensource driver

Strangely enough, I cannot reproduce it while having gnome's screen recording on.

The webm's in question are here: https://boards.4chan.org/gif/thread/17157855 <- WARNING: NSFW

Did you enable any of the widget.wayland options?

Strangely enough, I cannot reproduce it while having gnome's screen recording on.

The webm's in question are here: https://boards.4chan.org/gif/thread/17157855 <- WARNING: NSFW(In reply to Jan Alexander Steffens [:heftig] from comment #3)

Did you enable any of the widget.wayland options?

No, none of them are enabled. This happens with a webm's larger than a viewport while scrolling the page.
Btw my copy of firefox nightly is from https://pkgbuild.com/~heftig/repo/x86_64/

(In reply to Jan Alexander Steffens [:heftig] from comment #3)

Did you enable any of the widget.wayland options?

setting widget.wayland_vsync.enabled = true fixed the glitching webm's AFAICT
note: other widget.wayland settings were left at their default values

I can reproduce this using https://jsfiddle.net/zfvk0bmw/show/, by playing the video and scrolling down.

Is someone still able to reproduce this?

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #7)

Is someone still able to reproduce this?

Yes. See the jsfiddle URL provided by heftig.

(In reply to Mel from comment #1)

Compositor: Mutter 3.36.2 in wayland mode
GPU: AMD Radeon Rx580 with opensource driver

Ubuntu 20.04, Ubuntu on Wayland, mutter 3.36.2, Radeon RX480, Mesa 20.0.4, 2560x1440@60Hz
Debian Testing, Gnome Wayland, mutter 3.36.3, Macbook Pro: Intel Iris Graphics 6100 (BDW GT3), Mesa 20.1.1, 2560x1600@60Hz (2x scaling)

Hm. I still can't reproduce this bug with the following command. Can you?

$ pip3 install --upgrade mozregression
$ MOZ_ENABLE_WAYLAND=1 mozregression --launch 2020-06-26 --pref gfx.webrender.all:true gfx.webrender.max-partial-present-rects:1 -a https://jsfiddle.net/zfvk0bmw/show/

Do you have a non-60 Hz screen? Could this problem be limited to Arch Linux or the custom build from comment 4?

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #9)

Hm. I still can't reproduce this bug with the following command. Can you?

$ MOZ_ENABLE_WAYLAND=1 mozregression --launch 2020-06-26 --pref gfx.webrender.all:true gfx.webrender.max-partial-present-rects:1 -a https://jsfiddle.net/zfvk0bmw/show/

gfx.webrender.max-partial-present-rects:1 should be -1 or some higher number IIRC.

Personally I'm always using -1. My second attempt was above 1, but no difference.
(The only unrelated bug I see is that the video can be cut off (white) on the right at certain horizontal scroll positions, which is bug 1647156.)

Something's wrong with the official nightly, it seems. Enabling GNOME-Shell's damage region painting shows that the official build isn't posting any partial damage and just submitting the whole window, unlike my builds, which do show individual tiles getting updated.

You can toggle the damage region painting by entering the following into the looking glass console (run lg using Alt+F2):

• enable: Meta.add_clutter_debug_flags(0, Clutter.DrawDebugFlag.PAINT_DAMAGE_REGION, 0)
• disable: Meta.remove_clutter_debug_flags(0, Clutter.DrawDebugFlag.PAINT_DAMAGE_REGION, 0)

PS: Enabling damage region painting is also one way to disable the shell's partial redrawing optimization, so ironically the bug seems to disappear.

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #9)

Do you have a non-60 Hz screen? Could this problem be limited to Arch Linux or the custom build from comment 4?

I performed the steps you've asked and it's not reproducible on the build pulled in by mozregression tool.
To verify this, I manually downloaded nightly, unpacked it to /opt and ran my profile in it with gfx.webrender.max-partial-present-rects set to -1 and I can't reproduce the issue anymore. My screen is a 2560x1080@60 fwiw. Additionally tested with some webm's from which verifiably produce the glitch as described in #1.

Does closure of https://bugzilla.mozilla.org/show_bug.cgi?id=1653595 mean this bug is also fixed?

No, this is not fixed.

With EGL/Wayland, both STR of bug 1653595 are still reproducible:

bug 1653595 comment 0: MOZ_ENABLE_WAYLAND=1 mozregression --launch 20200925094208 --pref gfx.webrender.all:true gfx.webrender.max-partial-present-rects:1 -a https://www.youtube.com/watch?v=14yRFz8_iL8

bug 1653595 comment 4: MOZ_ENABLE_WAYLAND=1 mozregression --launch 20200925094208 --pref gfx.webrender.all:true gfx.webrender.max-partial-present-rects:1 -a https://docs.gitlab.com/ee/ci/yaml/README.html

bug 1656533 doesn't seem to fix bug 1653595 comment 4:
MOZ_ENABLE_WAYLAND=1 mozregression --repo try --launch fb2268db3e19a1401d0371ba0df78c405ecb2333 --pref gfx.webrender.all:true gfx.webrender.max-partial-present-rects:1 -a https://docs.gitlab.com/ee/ci/yaml/README.html

Did anyone already try to reproduce this on Android or Windows 8? In that case this would block bug 1640710 and get higher on the priority list of WR devs

Gnome Wayland, Intel HD Graphics 630 (KBL GT2), Debian Testing

(In reply to Darkspirit, Servo QA from comment #17)

With EGL/Wayland, both STR of bug 1653595 are still reproducible:

bug 1653595 comment 4: MOZ_ENABLE_WAYLAND=1 mozregression --launch 20200925094208 --pref gfx.webrender.all:true gfx.webrender.max-partial-present-rects:1 -a https://docs.gitlab.com/ee/ci/yaml/README.html

Not fixed by bug 1667297:
MOZ_ENABLE_WAYLAND=1 mozregression --launch 712ae51bbe6d --pref gfx.webrender.all:true gfx.webrender.max-partial-present-rects:1 -a https://docs.gitlab.com/ee/ci/yaml/README.html

Glenn, are you able to reproduce comment 17?

Yes, I can reproduce on Debian testing + gnome + wayland with the steps in c17.

Running at 4k, for each frame that gets rendered, WR is returning a dirty rect similar to Rect(5760x3240 at (12, -541)) (this changes based on scrolling position, of course).

That seems like it should encompass the entire screen, although it's not clamped to screen coordinates (maybe the logic in Gecko gets confused based on that?).

I haven't looked any further into it yet, to see if the external images are being drawn with correct bounds and clip, although that seems unlikely. The dirty rect provided above seems about right, but I haven't looked in any detail - could be missing something.

Yeah, it looks like this code tries to clamp the region to the framebuffer bounds at the same time as inverting the coordinate space, but does so incorrectly.

If webrender produces a dirty rect with a negative y value, and height greater than the framebuffer height, then that code first clamps that height to the framebuffer size, then uses the clamped height to calculate the dirty rect's bottom. Basically we need to change height to rect.size.height

When you submit a patch, please make sure to also apply it at https://searchfox.org/mozilla-central/source/gfx/webrender_bindings/RenderCompositorOGL.cpp#79

I can confirm this fixes the youtube and gitlab testcases. I'm not sure whether I can reproduce the jsfiddle one in the first place, but let's land this and hopefully someone else can test whether it fixes it.

(In reply to Robert Mader [:rmader] from comment #23)

When you submit a patch, please make sure to also apply it at https://searchfox.org/mozilla-central/source/gfx/webrender_bindings/RenderCompositorOGL.cpp#79

I was just about to forget about that, so thanks!

Webrender provides dirty rects with a top-left origin, whereas EGL
requires bottom-left. We also clamp the region to the framebuffer size
prior to passing it to EGL. There was a bug in this calculation when
the dirty rect had a negative y-offset and a height greater than the
framebuffer's height. This was causing too little of the screen to be
updated in some circumstances, resulting in stale content.

Note that this is only an issue when
gfx.webrender.max-partial-present-rects != 0.

Might be related:
When switching tabs, sometimes only the top-half of the window was updated and the bottom half was either the old tab or flickered strangely.
My impression is that this only occured with gfx.webrender.max-partial-present-rects != 0 (MOZ_X11_EGL=1, but with a Mesa version that doesn't support swap_buffers_with_damage on X11 yet).

https://hg.mozilla.org/mozilla-central/rev/7f3b6f4442eb

Seems to be fixed for me, thanks!

This has fixed the "typing comment text on youtube is invisible while the playing video is on the screen" thing for me, but revealed some glitches occasionally appearing over the IRCCloud UI that I haven't seen before: https://dl.unrelenting.technology/fx-new-dmg.mp4 — possibly bug 1668472 or bug 1656533 related?

(Also in the video you can see the long time bug with the link hover URL hint thing in the corner not doing damage for the previous size so when it goes from longer to shorter there's an artifact.. I guess this hasn't been tracked as a bug yet?)

Hmm, I'm not sure why that would have caused the irccloud regression, but it is tricky code so it's conceivable. Could you file a bug about that please?

It shouldn't be due to bug 1656533, we currently take the conservative approach and do a full render when buffer_age != 2. Could possibly be bug 1668472, or just as easily yet another bug.

I'm not aware of a bug for the url hover either

I had no luck to reproduce it, but such a tooltip bug was fixed for Windows partial present 6 months ago: bug 1624216

So far looks like the patches that landed (bug 1668472 most likely) fixed everything \o/