If I read correctly, wlrobs is currently using wlr-screencopy-unstable-v1 for capture, which I assume is what's causing sway's CPU usage to spike when capturing. If I understand correctly, the export dmabuf protocol should allow for much more efficient capture.
https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-export-dmabuf-unstable-v1.xml
The dmabuf protocol was actually what wlrobs was supposed to use when it was first being developed. The problem and reason I didn't use it is because of OBS. The ideal use case would be to never copy the frame off the GPU but I can't do that because OBS does not use EGL but instead uses GLX. EGL provides a way for me to create an OpenGL texture directly from the dmabuf exported from sway and then I could render that to OBS without ever doing a copy. With the way things are now I'd have to capture, copy, and then give to OBS which defeats the purpose of dmabuf. I've thought about taking the time to add an EGL backend to OBS to remedy this but it's something I have yet to get around to doing.
There is a relatively new PR to add an EGL backend to OBS: https://github.com/obsproject/obs-studio/pull/2097
Alright, I will definitely take a look at implementing this then
Initial support was added by d0c98d26d066 to the dmabuf branch. It MUST be used with the EGL backend or it will not work. It's also still got quite a few weird quirks such as it cannot be resized and the preview in the settings window is upside down. I haven't figured out exactly what causes either of these issues but seeing as it otherwise works and these are relatively minor issues I'd push it anyway.
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?
🤔 you're right...I Just did a framerate test and sure enough it's not capturing at 60FPS, this should really be made its own bug which I have done with #23. As far as debugging goes my starting point would be to determine if
_frame(),object(), andready()inside ofdmabuf_source.care actually called at 60FPS. I assumerender()will be, if for whatever reason that's not then it's an OBS problem which seems very unlikely. If I have time I might take a look at this however wofi v1.3 is higher on my priority list and that's been stuck in the pipeline forever, this will likely not be addressed by myself in a timely manner.