Linux: occasional white bar on top of fullscreen window

[kfj]

Dear all!
For some time, I've been wrestling with an annoying bug when running my SFML Program on Linux. When switching to fullscreen mode, I do at times get a white bar at the top of the screen. I have seen one bug report which has similar content: https://gitlab.gnome.org/GNOME/mutter/-/issues/2937
I tried every trick I could think of to find the place where things go wrong, but came to conclude that the windowing system messes with the window 'from the outside', because I do get Resize events with the wrong size (desktop height minus the white bar) without having triggered anything along these lines - the window is created with Fullscreen style. I use the Resize event to 'notice' that the bug is happening (it only occurs occasionally) and then I immediately re-create the window with fullscreen style. Usually one detect-recreate cycle is enough, but at times, the system is 'obstinate' and sends a few wrong Resize events before yielding to my re-creates. This produces a bit of flicker, but at least the erroneous state does not persist. I post here in case anyone else is having the same problem. Maybe my workaround can help, until there is a fix system-side which makes it unnecessary. Of course, a 'real' bug fix would be much appreciated!

This is the gist of my worlk-around code:

...
        if ( event.type == sf::Event::Resized )
        {
          auto window_size = p_window->getSize() ;

          if (    ui::run_fullscreen
               && ( window_size.y != desktop.height ) )
          {
             ui::p_screen->p_window->create ( desktop ,
                                      std::string ( "" ) ,
                                      sf::Style::Fullscreen ) ;
          }

[eXpl0it3r]

Are you using X11 or Wayland (or rather xwayland, given that SFML doesn't natively support Wayland)?

[kfj]

Sorry for not replying straight away, I did not see your response!

It happens with both X11 and Wayland on Gnome. I'm running a debian 12 system, with unstable packages activated, to make it close to a rolling release. SFML is built here from the 2.6.x branch. I had similar issues on a recent Ubuntu install. I think the problem may be with Gnome, and that it's not an X11/Wayland issue. Searching for a solution, I have, among other things, tried installing openbox, and there, the problem does not occur. My hope posting here was that maybe some of you guys who are 'deep inside' SFML can make something of the hint that, even though I request a full-screen window, I get the thing with the white bar on top, plus the SFML event telling me of the erroneous size. This only happens every now and then - I can toggle window/full-screen mode with a key, and sometimes I can switch to and from 5-6 times and all is well, sometimes my workaround fires once and I have the full screen, but sometimes I get the Resized event repeatedly, up to 5-6 times or so, until the system finally relents and gives me the proper full-screen, and every time I retry the screen flickers annoyingly, but at least the workaround holds - it saves me from having to toggle full-screen mode manually until the white bar disappears.

If you have a recent debian or ubuntu at hand, you can maybe try and see if you can reproduce the bug - I distribute binaries, the Linux version is in AppImage format, so all it takes is downloading it and making it executable. Load any image and press F11 repeatedly until you get the white bar thing (it may even show up straight away). Here's my Download page, just pick a recent AppImage:

https://bitbucket.org/kfj/pv/downloads/

If you need more info, I'll gladly help - this thing is bugging me big time. And if you could reproduce the bug, this would at least reassure me that it's not just my system (Intel® Core™ i5-4570 × 4, Intel® HD Graphics 4600 (HSW GT2)) acting up.

[kfj]

No helpful hints?

I have more problems which I think are related to Gnome:

- both with vsync and with a fixed frame rate, occasionally, the capped rate is not honoured and frames are consumed as they come. I expect Window::display() to block until a new frame can be displayed, instead it seems to return without delay as if there were no frame rate limit or vsync at all. This problem does not occur with openbox.

- sometimes, after program start in Fullscreen mode, the mouse pointer is confined to the outline of a rectangular region of the screen. Switching the Mouse Cursor off and on again removes the confinement. This is hard to reproduce, but when it occurs it's very annoying.

[eXpl0it3r]

To me it sounds like some Gnome issue, not sure if SFML can do much or anything about it.
Have you tried other games, do they experience the same issue or not?

It happens with both X11 and Wayland on Gnome.

Just to double check, when you say X11, you really switched to Xserver and aren't using just translation layer (xwayland, etc.), correct?

- both with vsync and with a fixed frame rate, occasionally, the capped rate is not honoured and frames are consumed as they come. I expect Window::display() to block until a new frame can be displayed, instead it seems to return without delay as if there were no frame rate limit or vsync at all. This problem does not occur with openbox.

Make sure you're not mixing vsync and frame rate limit, that can cause odd issues. Also check that you haven't disabled vsync globally. And ensure your GPU driver is up to date.

- sometimes, after program start in Fullscreen mode, the mouse pointer is confined to the outline of a rectangular region of the screen. Switching the Mouse Cursor off and on again removes the confinement. This is hard to reproduce, but when it occurs it's very annoying.

Is this again with X11 and Wayland?

[kfj]

To me it sounds like some Gnome issue, not sure if SFML can do much or anything about it.
Have you tried other games, do they experience the same issue or not?

I don't have any games. My Program is an image viewer. I also think it's a Gnome issue, or to be more precise, a mutter issue. I haven't seen the problems I describe with other programs, that's why I've come here to see if anyone else has had similar problems, and maybe a workaround - until the bugs are, hopefully, fixed on the Gnome side. My workaround to catch and react to the Resize events which contain the erroneous extent does work, but I was hoping for something more elegant. For the other two issues I haven't yet found anything.

It happens with both X11 and Wayland on Gnome.

Just to double check, when you say X11, you really switched to Xserver and aren't using just translation layer (xwayland, etc.), correct?

I used both. Outside a Linux session, you can choose which desktop environment you want for your next session, so I tried both 'Gnome' and 'Gnome with Xorg'. I think the first one uses wayland and xwayland, whereas the second uses plain X11. The problem occurs with both, but when I start a session with openbox instead, the problems are gone.
 

- both with vsync and with a fixed frame rate, occasionally, the capped rate is not honoured and frames are consumed as they come. I expect Window::display() to block until a new frame can be displayed, instead it seems to return without delay as if there were no frame rate limit or vsync at all. This problem does not occur with openbox.

Make sure you're not mixing vsync and frame rate limit, that can cause odd issues. Also check that you haven't disabled vsync globally. And ensure your GPU driver is up to date.

I sure won't try and mix the two. Normally I run with vsync enabled, beause I use a fixed delta loop. When I use fixed framerate instead, my system does not run smoothly. Nevertheless I have CL options to choose one or the other, and with both settings I get the problem I described: every now and then the 'brake' fails and I get 100% CPU load due to the frames being accepted without blocking. With debian12 and unstable packages activated, I should have the latest GPU drivers.

- sometimes, after program start in Fullscreen mode, the mouse pointer is confined to the outline of a rectangular region of the screen. Switching the Mouse Cursor off and on again removes the confinement. This is hard to reproduce, but when it occurs it's very annoying.

Is this again with X11 and Wayland?

Same thing, both on Gnome one on Gnome with Xorg.

[kfj]

Seems like the run-full-throttle bug has gone with the last updates - I haven't seen it any more. For the white-bar-on-top bug, my workaround in my initial post works okay, though I do get a bit of flicker if the erroneous size is detected several times in a row - this is, luckily, rare. Re. the third bug - the confinement of the mouse pointer - I needed some trickery. I have code to switch the mouse cursor on if there is mouse activity (like mouse moves, clicks, scroll wheel), and off if there is no activity for a little while. I intended to start my program with the mouse cursor off to avoid the bug, but try as I might the cursor was switched on. I finally tracked it down to a single MouseMoved event which occured without any interaction on my side. Is this an artificial event sent by SFML to provide the initial mouse position? If I catch and ignore the very first MouseMoved event, the mouse cursor remains off, as intended, and the bug does not seeem to occur any more.