Very nice! Can confirm this fixes the issue. Thank you for the prompt fix and great job!

Some preliminary information I was able to acquire, based on your comment in #7:

I used bpftrace to sample the calls to _frame(), object(), ready() and render(). Here is the number of invocations per second:

scpy:

_frame()/s: 0
object()/s: 0
ready()/s: 60
render()/s: 60

dmabuf:

_frame()/s: 30
object()/s: 90
ready()/s: 0
render()/s: 0

Oddly enough, here is dmabuf with the "Properties" dialog of the wlrobs source open (which has its own preview):

_frame()/s: 60
object()/s: 180
ready()/s: 0
render()/s: 0

and sure enough, recording while the Properties dialog is open results in smooth 60fps video 🤔

Using wlrobs with dmabuf (under Sway) seems to somehow produce lower performance than screencopy. With dmabuf the resulting 60FPS video is actually ~30FPS (aka the ~30FPS recording is simply encoded as 60FPS). With screencopy, despite the huge CPU usage spike, the output is smooth true 60FPS.

Any ideas how to debug this?