Closed Bug 1616894 Opened 5 years ago Closed 4 years ago

[Wayland/KDE] Firefox only refreshes on re-focusing with widget.wayland_vsync.enabled

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Platform:
Unspecified
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED MOVED

People

(Reporter: johnp, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

Enabling widget.wayland_vsync.enabled on KDE Plasma 5.17.5 (Fedora 31) causes Firefox to only refresh/redraw once a window is re-focused. With that pref set to false Firefox works, as long as one doesn't move or resize any window (bug 1593478).

(Jan Andre Ikenmeyer [:darkspirit] from bug 1633273 comment 3)

I just noticed that bug 1629140 caused a horrible performance regression (2 fps) for WebRender with native Wayland backend on KDE. Gnome is unaffected. Disabling widget.wayland_vsync.enabled fixes it. I will file a new bug about it.

(Robert Mader [:rmader] from bug 1632399 comment 14)

(In reply to Jan Andre Ikenmeyer [:darkspirit] from bug 1632399 comment 12)

(Maybe these popups now think that they are invisible? I have no idea what I'm talking about. That was my impression on KDE: I could increase webgl and video frame rate by constantly hovering different taskbar entries, otherwise it was 2 fps - probably caused by changing seconds of my clock.)

This sounds like a compositor bug - apparently not sending frame callbacks when it should. Mind creating an issue for it (checking kwinFT might be a option, too)?

Blocks: 1629140

Very likely a compositor issue, although I suspect it might be a regression, as I vaguely recall testing on KDE many moons ago.

Mutter had a similar bug, triggered by committing surfaces with frame callbacks but no new buffers, as we do in our vsyncsource as we do in our vsyncsource as frame scheduling is (unfortunately) not coupled to rendering.

PMed Roman Gilg on this. Given the current situation with kwin and kwinft (with stronger wayland focus), we should probably consider blacklisting kde for this feature by default for a while, until LTS versions are known to be fixed (when we reland bug 1629140).

kwin-wayland 4:5.17.5-2, Debian Testing, Macbook Pro
This seems to be an intermittent bug. A moment ago I could reproduce this problem even with 2019-11-28 (bug 1542808 comment 61), but now I can't anymore. The CSS animation seemed fine, video and WebGL were affected:
$ pip3 install --upgrade mozregression
$ MOZ_ENABLE_WAYLAND=1 mozregression --launch 2020-05-28 --pref gfx.webrender.all:true widget.wayland_vsync.enabled:true -a https://codepen.io/teerapuch/pen/vLJXeR -a https://upload.wikimedia.org/wikipedia/commons/5/5c/Teichschlucht_VP8.webm -a https://webglsamples.org/aquarium/aquarium.html

Testing again on Fedora 32 (Plasma 5.18.5 now) and latest Nightly the issue seems to be mostly gone (css animation, video and webgl are fine (no dmabuf), but scrolling and address bar typing are still choppy sometimes). I suppose frame callbacks are more consistent now, but instead I now have an input caret icon stuck on the screen, the mouse pointer is sometimes stuck in the dragging state and Firefox context menus are flickering/disappearing on mouse movement not on the context menu. The latter sounds again like some frame callback issue. Sometimes context menus are just fully black or do not become visible at all. Dropdowns are also sometimes invisible.

In addition, windows of other applications becomes fully translucent when placed above a Firefox window on my second monitor (with an opaque box around the mouse pointer), but not on my first monitor, so I don't think that's Firefox's fault.

Various other Plasma Wayland bugs (not related to Firefox at all) still exist (e.g., Konsole menus open on the wrong screen if a window is on two screens at once (Firefox opens its menubar menus fine); display configuration resetting on every login; ...), so I suppose Plasma Wayland is still not ready for day-to-day use :/

Not sure if it's worth it to keep this bug open at this point. I may just have to try kwinft at this point if I want to use Wayland productively.

edit: kwinft 5.18.1 has mostly the same issues.

Since Robert made me aware of this bug: I'm currently reworking subsurfaces in KWinFT and testing with firefox-nightly. Using the default config and changing the vsync.enabled option still does not work.

I would like to help with pinpointing the issue. Are you expecting something explicitly from the compositor? Above Kenny said "committing surfaces with frame callbacks but no new buffers". Does this mean when you receive a frame callback but have no damage you commit the same buffer again?

(In reply to Roman Gilg from comment #6)

Since Robert made me aware of this bug: I'm currently reworking subsurfaces in KWinFT and testing with firefox-nightly. Using the default config and changing the vsync.enabled option still does not work.

I would like to help with pinpointing the issue. Are you expecting something explicitly from the compositor? Above Kenny said "committing surfaces with frame callbacks but no new buffers". Does this mean when you receive a frame callback but have no damage you commit the same buffer again?

I mean that no buffers nor damage are submitted at all in the frame callback. The flow, either run on frame callback or when starting the vsync source, is:

struct wl_callback *callback = wl_surface_frame(surface);
wl_callback_add_listener(callback, &frame_callback_listener, data);
wl_surface_commit(surface);
wl_display_flush(display);

The actual code can be seen here: https://searchfox.org/mozilla-central/source/widget/gtk/WaylandVsyncSource.cpp#107. Unfortunately, vsync in Firefox is entirely disconnected from rendering, hence this odd (although valid) construct. Listeners for vsync (https://bugzilla.mozilla.org/show_bug.cgi?id=1645528) in Firefox may then render and cause a new buffer to be submitted as part of another commit.

Based on conversations in #wayland, it was concluded that this construct is valid (although suboptimal), and should result in frame callbacks being fired as long as the surface is eligible for frame callbacks. Presence of buffers and damage does not affect the eligibility. A bug in Mutter lead to frame callbacks stopping after a set period of time if damage was not being submitted.

To the best of my knowledge, a better implementation requires at least partially redesigning frame scheduling in Firefox. possibly lining more up with what Chromium is doing.

(feel free to needinfo me or find me in #wayland on freenode if you have questions)

I'm using KDE and have the Wayland back-end enabled. When I enable widget.wayland_vsync.enabled, the whole browser slows to a crawl. Any action I perform takes ~60 seconds to complete. I am currently using the release version 79.0 .

Can someone confirm that this still happens on 5.20?

I can confirm that the issue is still present in Plasma v5.20 . The browser becomes extremely slow with the vsync config toggled on.

I've merged a patch to make kwin schedule compositing on "empty" commits. The fix will be available in 5.21. Also, if you discover a bug in kwin, please use official channels to report issues (bugs.kde.org). We were notified about this problem only half a year(!) later, which is a lot of wasted time.

Closing this as fixed in KWin 5.21 now. This was indeed quite unfortunate, sorry from my site as well. With Fedora 34 enabling Wayland session and FF backend by default I hope we'll get a much better feedback loop in the future.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → MOVED
You need to log in before you can comment on or make changes to this bug.