10:17 <marcan> alyssa, lina: hey, so libwebrtc (firefox/chromium) PipeWire screencasting is super slow (when it works, see fedi for another bug). I assume that's the write-through mapping issue. would be nice if you could look at it and see if it can be fixed with a logic change in mesa, or if it's blatantly a libwebrtc screwup.

12:17 <alyssa> marcan: give https://gitlab.freedesktop.org/asahi/mesa/-/merge_requests/73 a try

12:17 <alyssa> and also review it

12:17 <alyssa> (Run your entire desktop with that debug flag. If you do gfx dev and use a login manager, don't. :p)

12:18 <alyssa> (Or force the flag on with a 1 line patch on top if that's easier)

12:51 <marcan> alyssa: from what I read the libwebrtc implementation should be doing modifiers properly, so it should be confined to the readback path once inside the browser and hopefully only needed for firefox/chromium

12:58 <handlerug> I want to note that PipeWire screencasting slows down significantly (with xdg-desktop-portal-wlr) with a game running (such as Celeste), but capturing the same game using obs-vkcapture gets you a silky smooth stream

13:06 <marcan> define "significantly". if the capture is like 3FPS, that's the writeback issue. if it's faster, that's something else.

13:08 <marcan> alyssa: speaking of overrides, maybe we should enable nofp16 for browsers? since there's always going to be broken WebGL stuff out there...

13:09 <marcan> I dunno what the policy is here, just an idea :p

13:28 <handlerug> btw hardware cursors don't work in sway/wlroots it seems (Falling back to software cursor on output 'eDP-1')

13:30 <handlerug> ok so I checked and it's probably not the writeback issue. when you start recording, xdg-desktop-portal-wlr (or pipewire?) switches to the "streaming" mode then spams "wlroots: no current buffer" followed by "pipewire: out of buffers" every frame. so it might be a different issue.

13:30 <ChaosPrincess> dcp driver currently only supports one plane iirc

13:30 <handlerug> ah that explains it

13:32 <bluetail> Explain like I'm 5: whats a plane in this context?

13:32 <handlerug> another data point: wf-recorder exhibits the same issue, and if you check the sway logs while recording with xdg-desktop-portal-wlr or wf-recorder, you can see sway spamming "[wlr] [types/output/render.c:282] Disabling direct scan-out on output 'eDP-1' (locks: 1)" and "[wlr] [types/output/render.c:282] Enabling direct scan-out on output 'eDP-1' (locks: 0)" alternating every frame

13:32 <ChaosPrincess> display output engines can compose several possiblly-transparent images into the actual display output

13:33 <handlerug> and both wf-recorder and xdg-desktop-portal-wlr use the same mechanism

13:33 <ChaosPrincess> and the cursor is quite often a movable transparent image that is not drawn on the main framebuffer, but composited in hw

13:33 <bluetail> Thank you for explaining :)

13:34 <marcan> that sounds like a bug in wlr (the perf and spamming, not the software cursor, though it might be related)

14:15 <handlerug> I was about to dismiss this issue as wlroots-specific, but I just installed Plasma and the same stuttering issue appears here as well (dunno about the logs, judging from the recording). still not writeback, but an issue nonetheless

14:22 <handlerug> hm, it's as if cursor movements trigger the freezes

14:42 <handlerug> demonstration: https://0x0.st/HNbl.mkv

14:43 <handlerug> it's fine if OBS is not recording/streaming, it's only when it's recording/streaming

14:43 <handlerug> oh let me make a better demonstration

14:45 <handlerug> here: https://0x0.st/HNb0.mkv

14:46 <handlerug> you can see the frame drops when the cursor moves. it's still not great when the cursor is still, but when it's moving the drops are much more severe

15:44 <lina> Interesting... I'll have to look at that, I wonder if all the Mesa changes that are queued made any difference so far (we did fix a while bunch of synchronization bugs... ^^)

15:46 <handlerug> nice, looking forward to that