obs-studio
obs-studio copied to clipboard
Multi monitor: Visual issues when moving window between screens or unmaximizing OBS's window with activated preview
Operating System Info
Other
Other OS
openSUSE TW KDE Plasma Wayland
OBS Studio Version
28.0.2
OBS Studio Version (Other)
No response
OBS Studio Log URL
https://obsproject.com/logs/zSjrTKjpoufDuj45
OBS Studio Crash Log URL
No response
Expected Behavior
- When moving OBS Studio's window between two screens, it does not show visual glitches, like ghost windows.
- When unmaximing OBS Studio's window on one screen, it does not cause a ghost window on the 2nd screen for a split second.
Current Behavior
Moving window between two screens
https://user-images.githubusercontent.com/93607429/192769613-f901ca9a-6a35-4871-b398-2da0554e805c.mp4
Unmaximizing the OBS window
https://user-images.githubusercontent.com/93607429/192769754-0dbf9d03-2dff-43ca-aec8-e845809506d5.mp4
Steps to Reproduce
Moving window between two screens
- Two screens, 2k@100% + 4k@200% (primary)
- Open OBS Studio
- Drag its window from one screen to another
or
Un-maximizing the OBS window
- Two screens
- Open OBS Studio
- Maximize its window
- Un-maximize the window by dragging its titlebar
Anything else we should know?
While the visual issue with un-maximizing window is always reproducible for me, the issue caused when moving the window is most reliably (if at all) reproducible, when I use a 100% and 200% scaling respectively, as described both.
See also https://bugs.kde.org/show_bug.cgi?id=455405#c5
It's a bug in obs. I know this because I debugged this glitch a while ago; but my intent was to fix repainting in kwin. Can you report this issue to obs developers please?
Do both behaviours disappear if you disable the preview?
Do both behaviours disappear if you disable the preview?
Both are no longer reproducible with deactivated preview.
This issue is complicated.
libobs
requires that the frontend passes a surface for it to draw the preview on. On X11, that's a child window. On Wayland, that's a subsurface. The surface painting time is not really bound to the compositor, i.e. it doesn't react to frame callbacks. Instead, it paints whenever libobs' graphics thread asks it to paint. To do that, it has to disable v-sync on that subsurface. Enter Qt, which sets the desync mode on the surface, because it wants to make Wayland behave as much as X11 as possible. The result of no vsync + desync mode + independent rendering is exactly what you see there. The preview subsurface updates its geometry at random times, practically always detached from the compositor rendering, and that's guaranteed to glitch.
I'm convinced that the only reasonable way to fix this is to make Qt default to sync mode, and I have tried to set that on OBS Studio subsurfaces manually, but it simply deadlocks. I did not investigate any further, there must be a deeper reason why Qt developers went with desync mode.