Screen flash on focus change

[Drakmyth]

I'm using SFML.NET 2.0 on Windows 7, though I think this issue is also being referred to by this thread which was using C++.

I have a dual monitor setup. I wrote a small app that opens a "fullscreen borderless window" on the primary monitor. I've noticed that whenever the window loses or gains focus (by clicking on something in the second monitor, tapping the windows key, or alt-tabbing) that both monitors present a quick black flash. It doesn't seem to affect functionality at all (I assume the window stops receiving updates, but I haven't actually tested that), so it is a very tiny issue, but it is somewhat annoying. I mainly bring this up as other programs/games that support "fullscreen borderless window" do not present this flash. Of course, this is likely due to however SFML handles focus changes internally.

The app:

using SFML.Graphics;
using SFML.Window;

namespace FocusApp
{
    public static class Program
    {
        public static void Main()
        {
            // Create the main window
            RenderWindow window = new RenderWindow(VideoMode.DesktopMode, "SFML window", Styles.None);

            // Start the game loop
            while (window.IsOpen())
            {
                // Process events
                window.DispatchEvents();

                // Clear screen
                window.Clear(Color.Red);

                // Update the window
                window.Display();
            }
        }
    }
}
 

Update 1: Of interesting note is that this only happens if the window is exactly the same as the monitor resolution. For reference, my native desktop resolution is 1920x1200 on my primary monitor. If, leaving the window borderless, I set the video mode to 800x600, it performs as I would expect and there is no flashing on focus change. If I set the video mode to 1920x1199 (which, admittedly, is probably unsupported but SCIENCE!) the window appears to work as expected, except that the start bar stays on top of it. If I set the video mode to 1920x1201, the window doesn't seem to appear at all (though this places it outside the monitor bounds, and again is likely unsupported) but the icon is still visible on the start bar. Tests with the border turned on resulted in the exact same results as borderless, except that the black flash doesn't NOT occur when the window resolution matches the desktop resolution.

Update 2: It seems the window not appearing thing is already a known issue and it looks like that issue was resolved about a week ago. Would anyone happen to know if this flashing issue I've come across got resolved as a part of that one? I could, of course, download and build the sources myself to find out (I assume, does the .NET binding source stay up-to-date alongside the c++ build?) but if anyone already knows it would save me the trouble.

[Drakmyth]

With the release of SFML/SFML.NET 2.1, I've tried this again and the results have changed somewhat. Creating a borderless window less than the monitor resolution functions as before, with no flash occurring on focus change but the Start bar staying in front of the window.

Creating a borderless window larger than the monitor resolution now functions exactly the same way, so the issue of the window not appearing has indeed been fixed.

A borderless window with the same resolution as the monitor will now cause the flash after the first focus change, but from then on will act the same as the above two scenarios, no longer flashing, but showing the start bar in front of the window. This, unfortunately seems to be a little worse than in 2.0 as it is the most common scenario and while before the visual flash was merely a minor annoyance, the start bar staying in front of the window creates usability issues. It does seem that alt-tabbing back to the window brings it to the foreground (in front of the Start bar, and causes the flash) but merely clicking on the window to bring it into focus does not.

Is there a step I'm missing in the initialization of the window that would solve this problem, or would the appropriate next step be to file a bug report?