libretro
[Video/Wayland] Strange checkered pattern window is created when RA is run in fullscreen mode.
Description
A strange small window with a checkered pattern is created when RA is run on Wayland in fullscreen mode. In other words: Instead of directly creating a fullscreen window, a small non-fullscreen window filled with a checkered pattern is created, which is visible for 1 second or so, and then RA appears in fullscreen mode.
This doesn't happen on KMS/DRM or X11, so it's a very strange thing to happen on Wayland only.
Expected behavior
If fullscreen is set, RetroArch should simply start in fullscreen and that's it, as any other program run in fullscreen mode.
Actual behavior
a small non-fullscreen window filled with a checkered pattern is created, which is visible for 1 second or so, and then RA appears in fullscreen mode.
Steps to reproduce the bug
- Run RetroArch in Wayland (NOT XWayland, but native Wayland) with fullscreen ON using Weston or an WLRoots-based compositor.
- Watch the screen for a strange window that appears before the actual RetroArch window.
Bisect Results
To my knowledge, it has always happened with the Wayland backend.
Version/Commit
Latest GIT code.
Environment information
- OS: GNU/Linux on Armhf, aarch64, x86_64... The problem doesn't depend on CPU arch, GPU or operating system or wayland-related libs versions.
- Compiler: gcc version 10.2.1 (But again, this is not caused by the compiler)
Additional information: I suspect that the Wayland backend is creating a non-fullscreen window, and then setting it fullscreen if that's activated on the RA options, thus causing this somewhat ugly behavior. But I don't know enough about the Wayland API to be sure. Any pointers to experiment and confirm my theory would be nice!
You're correct, it's the window before it gets made full screen. I made a lot of changes to the Wayland driver and thought it would be more diagnostic than a black rectangle when people reported an issue. It can easily be changed here.
@ColinKinloch Could this window that shows up before fullscreen be related to this issue I created just now? https://github.com/libretro/RetroArch/issues/14481
@ColinKinloch Maybe it could be set to black by default and set to checkered when debug is on?
Also, I have been building and testing with the draw_splash_screen() call removed altogether, and RetroArch starts much faster with no strange windows created, as other Wayland games/frontends do.
I suspect that whetever draw_splash_screen() was supposed to do isn't necessary anymore.
Could it be removed too, please? I see no other Wayland programs doing that strange windows shenanigans when they start.
It allows you to select what monitor to use, but only when fullscreen.
When Monitor Index is set to 0 (Auto) the window makes retroarch go full screen on whichever monitor the cursor is currently on rather than the "first" monitor.
Okay, seems it's no longer needed. I wonder what's changed.
libwayland, protocols, WLRoots and independent compositors are always improving, so I am not surprised if it's not needed anymore. Great!
Sorry, I was mistaken. It causes the RetroArch to go full screen on the display the cursor is on. Without it RetroArch always goes full screen on the same display.
@ColinKinloch I understand. Well, at least the checkered pattern will depend on debug being on?
Also, RetroArch going fullscreen on the same display is the right thing to do, I think.
After that, the user must select a display in video->output, and that will be the one to use in next RetroArch launch. So draw_splash_screen() can be removed I think.
Having RA going fullscreen on the display where the cursor is at seems very confusing and different to how other backends work.
It causes the RetroArch to go full screen on the display the cursor is on.
@ColinKinloch Not sure I understand. As things stand now, with the splash screen, when set to Auto, RetroArch starts on the monitor where the cursor is. Is that right?
Having RA going fullscreen on the display where the cursor is at seems very confusing and different to how other backends work.
@vanfanel Even if it might be confusing, that is the standard behaviour I've seen on other games when I'm on a Wayland session. I've tested with Age of Empires 2 Definitive Edition and with Tabletop Simulator on KDE, and they both start on the screen where the cursor is.
@nfp0 that's correct.
Most applications go fullscreen on the display they are currently open on. This is relatively intuitive. However this doesn't work for the wayland backend for RetroArch because it creates a new window during this transition. My only submissions to this project have been improving the wayland backend so I'm unsure whether it's possible with RetroArchs current design to reuse a window.
Yes, it would be more intuitive to go fullscreen on the screen the window is currently on. So, what you mean is that the current slash screen is not achieving it's purpose and can be removed? Did I get that right?
The problem doesn't seem too troublesome though, as most of the time the cursor will be on the screen where RetroArch is open anyway. And if not, it's fairly easy to transport the fullscreen window to other screens on most Wayland compositors. I've just tested on KDE Plasma Wayland and RetroArch handled the change in screen and resolution very well.
My point is that the splash screen is serving the purpose it was created for: Giving the user some control over which monitor RetroArch becomes fullscreen on.
The wayland protocol leaves it up to the compositor to decide where a new window is created. On my computer (gnome-shell) it places it on the monitor the cursor is currently on.
When transitioning a window to fullscreen there is an option to specify which monitor to use:
Specifying NULL leaves it is up to the compositor to decide:
- if the window has been realized (is on screen) it will go fullscreen on the monitor the window is currently on.
- If the window has not been realized it seems to select the bigger display.
RetroArch recreates the window when transitioning between states (going fullscreen, launching content) therefore the context of which monitor it's using is lost.
So without the splash screen:
- Launch RetroArch fullscreen on monitor A
- Drag it on to monitor B
- Use the mouse to launch content
- RetroArch launches the content on monitor A
Does the driver RetroArch API have a way to keep a window in existence from launch to exit? It would speed up launch and generally improve UX.
@ColinKinloch My understanding is that RetroArch lets us select the display index in video settings. That's enough for display selection, and of course the setting can be saved. No need for the ugly, slow splash-screen IMHO.
So without the splash screen:
Launch RetroArch fullscreen on monitor A Drag it on to monitor B Use the mouse to launch content RetroArch launches the content on monitor A
@ColinKinloch Have you tested this behaviour recently or ir is what you observed back then?
I want to test this on my KDE desktop. I've removed the if (!draw_splash_screen(wl)) line, but then RetroArch starts on my main screen (1440p) at the resolution of my secondary screen (1080p), filling the top-left corner of the screen.
@ColinKinloch Going back to this, did you look at the RetroArch display selection feature? It lets the user pick up a display. Please look at: Settings->Video->Output->Monitor Index Once selected, that monitor is used. No need to get a monitor auto-assigned with the splash screen hack.
@ColinKinloch I understand... And the splash screen could be avoided if RetroArch had a way to keep the same window open during all the RetroArch execution, right?
But again, how does SDL2 do it? And.. what about making the splash window "invisible" somehow?
I don't think SDL2 does do it. I think most SDL programs only create one window during execution.
I had a look at the Android RetroArch code since it doesn't get a new surface to render to for the launch of a new core. I've not had time to make a proof of concept though.
If there is only one monitor available or if the user has chosen a monitor index different from “0 (Auto)” (settings->uints.video_monitor_index != 0), then there should be no need to draw the splash screen, right? I think it should be made conditional, if it is not useful in the two cases mentioned above.
@Scall Sounds good to me! @ColinKinloch How does it sound to you? May I do a PR for what Scall said?