[Bug 50717] New: Wine places 1x1 pixel window on top of fullscreen window, blocking direct scanout on Wayland
https://bugs.winehq.org/show_bug.cgi?id=50717 Bug ID: 50717 Summary: Wine places 1x1 pixel window on top of fullscreen window, blocking direct scanout on Wayland Product: Wine-staging Version: 6.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: tempel.julian(a)gmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- KWin developer Xaver Hugl found this while investigating the cause of direct scanout getting blocked with Wine fullscreen windows on Wayland: "Wine puts a 1x1 pixel big override-redirect window on top of the fullscreen window that stops direct scanout. I'll add a workaround for now but at first glance looks like a Wine bug to me." https://invent.kde.org/plasma/kwin/-/merge_requests/718#note_191539 "I verified that it isn't caused by Xwayland / happens on a normal X session as well" https://invent.kde.org/plasma/kwin/-/merge_requests/728#note_191637 (this MR also contains the workaround, and indeed it makes direct scanout work with Wine) As a result, performance of fullscreen 3D Wine applications on Kwin Wayland git-master is negatively affected, as unnecessary compositing affects frame presentation and causes lots of dropped frames under high GPU load. It is well possible that this also negatively affects Gnome and Sway Wayland, but also Gnome unredirecting on Xorg. -staging and Proton are affected, might also apply to regular wine. It doesn't matter if WineD3D or DXVK is used (as this probably is very specific to Wine's window management and not the 3D API). It looks like if the proper fix was if Wine wouldn't spawn the 1x1 pixel window on top anymore. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50717 Bednar <bednarczyk.pawel(a)outlook.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bednarczyk.pawel(a)outlook.co | |m -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50717 --- Comment #1 from Zebediah Figura <z.figura12(a)gmail.com> --- Can you please test with upstream (non-staging) wine first? It also may very well be that the program itself is creating this window, not Wine. What application is this? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50717 --- Comment #2 from tempel.julian(a)gmail.com --- Created attachment 69577 --> https://bugs.winehq.org/attachment.cgi?id=69577 1x1px unmanaged window -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50717 --- Comment #3 from tempel.julian(a)gmail.com --- I've confirmed the issue with regular wine 6.2 with a clean prefix: Start Windows version of Unigine Valley with D3D11 -> WineD3D. The launcher doesn't trigger the 1x1px unmanaged window, but as soon as you start the actual program with 3D rendering, the 1x1px unmanaged window occurs. It apparently occurs with any 3D game in Wine. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50717 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Product|Wine-staging |Wine Component|-unknown |-unknown CC|leslie_alistair(a)hotmail.com | |, z.figura12(a)gmail.com | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50717 Rémi Bernon <rbernon(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon(a)codeweavers.com --- Comment #4 from Rémi Bernon <rbernon(a)codeweavers.com> --- It's most probably the "dummy parent" window used to reparent stale client windows. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50717 --- Comment #5 from Rémi Bernon <rbernon(a)codeweavers.com> --- Created attachment 69709 --> https://bugs.winehq.org/attachment.cgi?id=69709 Possible fix Is something like that helping in any way? Instead of creating an override-redirect window, which will bypass the window manager and possibly stay on top of all windows, it uses EWMH desktop window type / below all state to try to hide the dummy parent as much as possible without bypassing the window manager. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50717 --- Comment #6 from tempel.julian(a)gmail.com --- I can confirm that your patch prevents the unmanaged window to spawn. It turned out that also Wine's system tray icon feature can be problematic (e.g. Battle.Net client), as it (independently of the desktop environment?) spawns a 100% translucent window with on-top property. Is it really necessary that it is always on top? This can make it placed on top of fullscreen windows and thus can/does prevent direct scanout as well. As a result, an exception for 100% translucent windows was added to kwin's direct scanout feature, but this is probably better also fixed at the root? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50717 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fgouget(a)codeweavers.com Keywords| |patch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50717 Alex Folland <lexlexlex(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lexlexlex(a)gmail.com --- Comment #7 from Alex Folland <lexlexlex(a)gmail.com> --- Is Rémi's patch in comment 5 still applicable? If so, is there a chance of having it applied to upstream wine any time soon? If so, this fix sounds like it would be better to get in to wine 7.0 than not. This is just my opinion. Thanks for the patch, Rémi! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50717 --- Comment #8 from Rémi Bernon <rbernon(a)codeweavers.com> --- Well I'm not completely sure the patch is not going to cause any regression, as it will change the way the dummy parent window is created. I'm expect that if the window manager reports STATE_BELOW and WINDOW_TYPE_DESKTOP support it's hopefully going to work fine, but who knows that WM can do with it... As the comment above suggests it also looks like it's not the only problem and I don't have anything for the systray. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50717 --- Comment #9 from Alex Folland <lexlexlex(a)gmail.com> --- That full-screen translucent window issue sounds like it may be an issue for another issue report, and therefore may be fixable independently of the issue this report specifies. Does that sound right, or is this issue meant to capture all ways that wine can prevent Wayland direct scanout? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla