1723323 - buffer age or partial present/GLX or EGL/KDE/Nvidia: Firefox windows sometimes go black before redrawing content (Side info: When hovering taskbar preview while compositing is enabled, Firefox and glxgears freeze until they get resized)

Status: RESOLVED INACTIVE

(Core :: Graphics: WebRender, defect)

Description

[Stephan Sokolow]

Attachment: about_support.txt

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

Steps to reproduce:

1. Upgrade to Kubuntu Linux 20.04 LTS
2. Don't turn off taskbar thumbnails like I did on Kubuntu Linux 16.04 LTS
3. Disable desktop compositing because it inevitably causes drawing glitches with window decorations after a short period of time

(The drawing glitches are the window decorations going black more persistently than Firefox does, but since no application but Firefox experiences these symptoms with compositing disabled, I consider it Firefox's bug for being susceptible, even if the inciting cause turns out to be a bug in KWin or the nVidia binary video drivers.)

Actual results:

In response to certain events, Firefox windows (but not those of any other applications) will go black except for some subrectangle (possibly entirely black, but I haven't confirmed that) for anywhere between an instant (i.e. it flickers black) and three seconds.

The "except for some subrectangle" doesn't seem to correspond to the structural boundaries of any XUL or HTML DOM element, but it might correspond to some kind of partial updates since, when I test it on this page, the rectangle that remains visible (Which I've seen as small as roughly 100x100 or as large as something on the order of 700x300) never seems to omit the location of the blinking text cursor and sometimes (but not always) matches the boundaries of the paragraph the cursor is in.

One reliable way to trigger this seems to be to have four or five Firefox windows open, some entirely hidden behind others, and then scrub the mouse over the taskbar to flip through the thumbnail-containing tooltips. Sometimes the actual window will go black, sometimes the thumbnail, and sometimes both.

On at least some windows (may be dependent on page content), just holding the mouse over one taskbar button for a second or two will trigger the bug and, when I tested with a window containing the editing view for my WordPress blog (not focused and partially obscured by other windows), it would stay black for the shorter of either several seconds or when my mouse cursor transited over top of an uncovered portion of the browser window.

As far as I can tell, when testing on this page in the active window, the sequence of events goes as follows:

1. Mouse over the taskbar button
2. Popup appears
3. If the window doesn't go black immediately, it will soon
4. A visible rectangle containing the blinking text cursor is left over
5. When the cursor change state (ie. appears or disappears), that banishes the blackness

(Which suggests to me that whatever is going on is causing partial updates to sometimes get blitted to a zeroed buffer rather than to the old window contents.)

Expected results:

Like my other applications, Firefox windows should not blit partial updates onto black.

(Examples of applications which don't demonstrate this problem include Chromium, Blender, PCManFM, Konsole, gVim, FeatherPad, LibreOffice, Inkscape, Tellico, Pidgin, BasKet Note Pads, KeePassXC, Yakuake, Geeqie, GIMP, and, as far as I can tell, Thunderbird 78.11.0.)

...and I know at least Geeqie's image view widget performs partial updates because it had an off-by-one bug for ages that could be triggered by dragging another window across its image view widget with compositing disabled.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Martin Stránský [:stransky] (ni? me)]

Can you please create a screencast of the issue? How-to is here:
https://help.gnome.org/users/gnome-help/stable/screen-shot-record.html
Thanks.

Comment 3

[Stephan Sokolow]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #2)

Can you please create a screencast of the issue? How-to is here:
https://help.gnome.org/users/gnome-help/stable/screen-shot-record.html
Thanks.

I run KDE and have spent the last few distro update cycles ripping out more and more GTK-based applications as GTK has made it harder and harder to keep GNOME 3'a more-alien-than-macOS UX out of non-GNOME GTK apps.

Do you have an alternative set of instructions?

Comment 4

[Martin Stránský [:stransky] (ni? me)]

Maybe https://pointieststick.com/2020/07/24/this-week-in-kde-screencasting-and-shared-clipboard-on-wayland/ ?

Comment 5

[Stephan Sokolow]

Attachment: simplescreenrecorder-2021-08-04_07.55.35.mp4

I'm running X11 with the nVidia binary drivers and Kubuntu 20.04 LTS (which was feature-frozen months before the changelog you linked), but I did a quick google and found that https://www.maartenbaert.be/simplescreenrecorder/ is apparently the go-to package for my use-case.

Note that, when things go black in the video, it extends into the browser chrome but excludes the titlebar, and that though the "part remained visible" case did appear to align with DOM boundaries in this case, it sometimes doesn't.

(And yes, that's not a screen recorder glitch. That screen recording captured exactly what I was seeing.)

Comment 6

[Stephan Sokolow]

Oh, and...

• While I had to focus the window to get it to start bugging out this time, that's not normally the case. I'm not sure if that's because enabling the screen recorder affected the behaviour or if it's because I only ever noticed the "happens without the window being focused" case on non-Bugzilla tabs.
• When I say it sometimes doesn't align with DOM boundaries, an example would be that I sometimes see the non-black rectangle on this very bug thread, corresponding to to a vertical slice the same height as seen in the screencast but only extending from the left edge seen to about the "19" in "19 minutes ago". (Or to something that does appear to be DOM-aligned, but limited to just the text entry widget containing a blinking cursor.)

Also, note that I am running an up-to-date Firefox... I just used userChrome.css to reverse what I consider to be misdesigns in the new theme, such as re-attaching the active tab to the content pane like every other tab widget in every other application I can think of except macOS Safari's controversial new design.

Comment 7

[Martin Stránský [:stransky] (ni? me)]

Can you try to disable WebRender and try again?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Check_WebRender
Thanks.

Comment 8

[Stephan Sokolow]

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

Can you try to disable WebRender and try again?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Check_WebRender
Thanks.

With a Mozilla build of 91.0.2 (64-bit):

1. With the default behaviour ("Compositing: WebRender"), I re-confirmed the existence of the problem
2. Disabling WebRender by running it as MOZ_WEBRENDER=0 ./firefox (confirmed as "Compositing: Basic"), I was no longer able to reproduce the problem.

Comment 9

[Darkspirit]

Ubuntu 21.04, GTX 1060, Nvidia driver 470.63.01
This seems similar to bug 1710400, although this is on Nvidia.

mozregression --launch 91 --pref gf.webrender.all:true
mozregression --launch 2021-09-21 --pref gfx.webrender.all:true gfx.x11-egl.force-disabled:true

KDE with compositing:

• Task bar window preview sometimes shows the top-left quarter of the window at first, the rest is transparent, then it shows the rest and the preview is complete.
  (This reminds me of bug 1630251, or the opposite of bug 1678804)
• It completely freezes the actual Firefox window until I resize it.

KDE without compositing:

• screencast comment 5

Comment 10

[Darkspirit]

With compositing enabled:
Also reproducible with MOZ_X11_EGL=1.
MOZ_GTK_TITLEBAR_DECORATION=none or system do not help. (bug 1502519)

Comment 11

[Darkspirit]

This is a super old bug. I went back in 3-month-steps and "KDE with compositing" STR (incl. fixed by resize) is still reproducible with:
MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --launch 2013-11-21 --pref layers.acceleration.force-enabled:true

Comment 12

[Darkspirit]

This seems to be a bug outside of Firefox.
With compositing enabled, I can reproduce this bug even with $ glxgears. It freezes after I hover and unhover the taskbar preview. It can be fixed by resizing the glxgears window.

Comment 13

[Stephan Sokolow]

(In reply to Darkspirit from comment #12)

This seems to be a bug outside of Firefox.
With compositing enabled, I can reproduce this bug even with $ glxgears. It freezes after I hover and unhover the taskbar preview. It can be fixed by resizing the glxgears window.

However, Firefox is still the only application I've found which exhibits the problem with compositing disabled. (various GL-based GUIs such as the editor/IDE for the Godot game engine included.)

Comment 14

[Darkspirit]

With compositing disabled there seems to be a regression range. Still narrowing it down.

Comment 15

[Darkspirit]

Compositing disabled was affected by bug 1663273 on 2020-11-12.

Comment 16

[Darkspirit]

Let's focus this bug entirely on KDE without compositing: comment 5

MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 2020-05-21 --bad 2020-12-06 --pref gfx.webrender.all:true gfx.x11-egl.force-disabled:true

18:36.76 INFO: Last good revision: 12ead8ec653044ff347bfb8f68d68ceff945fb3a
18:36.76 INFO: First bad revision: 78ef1dbccb7a19fdfe31c79425b380401cf73f83
18:36.76 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=12ead8ec653044ff347bfb8f68d68ceff945fb3a&tochange=78ef1dbccb7a19fdfe31c79425b380401cf73f83

78ef1dbccb7a19fdfe31c79425b380401cf73f83 Martin Stransky — Bug 1663273 - Update shape mask setup, r=rmader
99e75de2454e4c0443357616ccf55e627e905cf4 Tim Nguyen — Bug 1677247 - Followup: reformat downloads.css a bit. DONTBUILD

It seems one bug was traded against another.

Comment 17

[Darkspirit]

EGL seems to make this less likely to occur.
EGL also makes bug 1678804 and bug 1729900 comment 6 less likely to occur.

Comment 18

[Darkspirit]

(In reply to Stephan Sokolow from comment #8)
Can you confirm that setting gfx.webrender.allow-partial-present-buffer-age=false or gfx.webrender.max-partial-present-rects=0 and restarting Firefox fixes this bug for you?

comment 5 reproducible:
mozregression --launch 92 --pref gfx.webrender.all:true gfx.x11-egl.force-disabled:true
mozregression --launch 2021-09-21 --pref gfx.webrender.all:true gfx.x11-egl.force-disabled:true
MOZ_X11_EGL=1 mozregression --launch 2021-09-21 --pref gfx.webrender.all:true

comment 5 apparently not reproducible:
mozregression --launch 92 --pref gfx.webrender.all:true gfx.x11-egl.force-disabled:true gfx.webrender.allow-partial-present-buffer-age:false
mozregression --launch 2021-09-21 --pref gfx.webrender.all:true gfx.x11-egl.force-disabled:true gfx.webrender.allow-partial-present-buffer-age:false
MOZ_X11_EGL=1 mozregression --launch 2021-09-21 --pref gfx.webrender.all:true gfx.webrender.allow-partial-present-buffer-age:false

mozregression --launch 92 --pref gfx.webrender.all:true gfx.webrender.max-partial-present-rects:0
mozregression --launch 2021-09-21 --pref gfx.webrender.all:true gfx.webrender.max-partial-present-rects:0
MOZ_X11_EGL=1 mozregression --launch 2021-09-21 --pref gfx.webrender.all:true gfx.webrender.max-partial-present-rects:0

Comment 19

[Stephan Sokolow]

Sorry for taking so long.

Either gfx.webrender.allow-partial-present-buffer-age=false or gfx.webrender.max-partial-present-rects=0 appears to fix the bug.

I didn't test both in combination.

Comment 20

[Darkspirit]

(Best reproducible with a blinking cursor in the address bar.)

Comment 22

[andysem]

Since my bug was marked as duplicate, I'd like to note that in my case the issue reproduces with compositing enabled (i.e. the bug is not limited to compositing disabled).

Also, I have the following environment variables that affect Nvidia driver and KWin:

KWIN_TRIPLE_BUFFER=1
KWIN_USE_BUFFER_AGE=0
KWIN_PERSISTENT_VBO=1
__GL_YIELD="USLEEP"
__GL_SYNC_TO_VBLANK=1
__GL_THREADED_OPTIMIZATIONS=1
__GL_SHADER_DISK_CACHE_SIZE=4294967296

TripleBuffer is enabled in xorg.conf. I wonder if Stepan and others who have this issue also have triple buffering enabled?

Also, for reference, there is this Nvidia forum thread that was started long ago and cites problems with black textures in KDE and elsewhere, presumably caused by GLX_EXT_buffer_age.

https://forums.developer.nvidia.com/t/black-or-incorrect-textures-in-kde/55110

Presumably, the same problem is present with EGL_EXT_buffer_age that is used by Firefox. Maybe Firefox should blacklist EGL_EXT_buffer_age on Nvidia driver by default?

Comment 23

[andysem]

Attachment: about:support page contents

Here are my about:support contents. Note that I have EGL enabled.

Comment 24

[Stephan Sokolow]

(In reply to andysem from comment #22)

Since my bug was marked as duplicate, I'd like to note that in my case the issue reproduces with compositing enabled (i.e. the bug is not limited to compositing disabled).

Also, I have the following environment variables that affect Nvidia driver and KWin:

KWIN_TRIPLE_BUFFER=1
KWIN_USE_BUFFER_AGE=0
KWIN_PERSISTENT_VBO=1
__GL_YIELD="USLEEP"
__GL_SYNC_TO_VBLANK=1
__GL_THREADED_OPTIMIZATIONS=1
__GL_SHADER_DISK_CACHE_SIZE=4294967296

TripleBuffer is enabled in xorg.conf. I wonder if Stepan and others who have this issue also have triple buffering enabled?

According to export | grep ..., the only one of those I have enabled is __GL_SYNC_TO_VBLANK=1 and this is the only display-relevant content in my xorg.conf or xorg.conf.d:

Section "Device"
    Identifier  "Default Device"
    Option      "NoLogo"        "True"
    Option      "nvidiaXineramaInfoOrder"       "DFP-0"
    Option      "metamodes" "DP-0: nvidia-auto-select +0+56, DVI-I-1: nvidia-auto-select +1280+0, HDMI-0: nvidia-auto-select +3200+56"
EndSection

Comment 25

[Darkspirit]

Still reproducible with GLX and EGL when setting gfx.webrender.force-partial-present=true.

Comment 26

[Robert Mader [:rmader]]

(In reply to Darkspirit from comment #25)

Still reproducible with GLX and EGL when setting gfx.webrender.force-partial-present=true.

Hi Jan, is this still reproducible for you?