https://bugs.winehq.org/show_bug.cgi?id=57456
Bug ID: 57456 Summary: Wine wayland scaled window is positioned on the left, not centered Product: Wine Version: 9.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winewayland Assignee: wine-bugs@winehq.org Reporter: shtetldik@gmail.com Distribution: ---
Created attachment 77451 --> https://bugs.winehq.org/attachment.cgi?id=77451 Vampire: The Masquerade - Redemption intro video scaled
When fullscreen resolution is set to something low and different from aspect ratio of the monitor, winewayland scales it up, but positions it on the left, rather than in the middle of the screen and leaves the mismatching area transparent.
This happened for example in the intro video of Vampire: The Masquerade - Redemption. The video is 640x346 and my screen is 2560x1440.
See attached screenshot for how it looks.
It would be better if the scaled window was positioned in the middle, with some black bands for areas that are caused by mismatch in aspect ratio.
Even better if this behavior could be configurable, i.e. where to position, what to use for bands, like transparent, solid color / what color, etc.
https://bugs.winehq.org/show_bug.cgi?id=57456
alexandros.frantzis@collabora.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexandros.frantzis@collabo | |ra.com
--- Comment #1 from alexandros.frantzis@collabora.com --- (In reply to Shmerl from comment #0)
Created attachment 77451 [details] Vampire: The Masquerade - Redemption intro video scaled
When fullscreen resolution is set to something low and different from aspect ratio of the monitor, winewayland scales it up, but positions it on the left, rather than in the middle of the screen and leaves the mismatching area transparent.
This happened for example in the intro video of Vampire: The Masquerade - Redemption. The video is 640x346 and my screen is 2560x1440.
See attached screenshot for how it looks.
It would be better if the scaled window was positioned in the middle, with some black bands for areas that are caused by mismatch in aspect ratio.
Even better if this behavior could be configurable, i.e. where to position, what to use for bands, like transparent, solid color / what color, etc.
In such cases winewayland currently marks the window as fullscreen and relies on the compositor to properly place it on screen, add black background etc. This behavior is mandated by the specification but some compositors don't implement it yet.
If this is on KDE Plasma then see https://bugs.kde.org/show_bug.cgi?id=461063.
https://bugs.winehq.org/show_bug.cgi?id=57456
--- Comment #2 from Shmerl shtetldik@gmail.com --- Thanks for the pointer, added a reference to this bug there.
https://bugs.winehq.org/show_bug.cgi?id=57456
--- Comment #3 from Shmerl shtetldik@gmail.com --- Pinged KWin developers, they said this is planned but will take a long time to implement due to complexity of the spec.
Wine can do this itself too. Quoting:
do it like other Wayland client that scales things in fullscreen - black 1x1 subsurface for the background + viewporter to scale the window(s) themselves
If it's too complex for Wine as well, I guess KWin users will have this broken until later.
https://bugs.winehq.org/show_bug.cgi?id=57456
--- Comment #4 from Shmerl shtetldik@gmail.com --- I re-tested it with VtM Redemption which has low resolution video intros, and somehow it works better now with scaling things. Not sure if winewayland improved it or KWin did?
Wine: 10.3 KWin: 6.3.2
https://bugs.winehq.org/show_bug.cgi?id=57456
--- Comment #5 from alexandros.frantzis@collabora.com ---
Not sure if winewayland improved it or KWin did?
I did a (Wine) bisection and it turns out that enabling EGL_EXT_present_opaque is what triggers the behavioral change in KWin. I also tried explicitly setting the wl_surface opaque region (while EGL_EXT_present_opaque was disabled) and got the same behavior (surface centered + black background). So KWin seems to be treating fully-opaque surfaces differently from non-opaque for fullscreen purposes (I don't know if such behavior was introduced recently or has been there for some time). I guess all this is in line with protocol changes the KDE folks are proposing (e.g., https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/37...).
https://bugs.winehq.org/show_bug.cgi?id=57456
--- Comment #6 from Shmerl shtetldik@gmail.com --- Btw, just for the reference, it's better in general but there is a brief flickering transparency moment when it just starts. I guess it depends on when exactly the scaling or positioning happens.