Love2d flashing when changing focus in fullscreen

[FormularSumo]

When I have Love2d open in fullscreen, desktop or exclusive, or borderless, changing focus causes the windows to flash briefly.

https://user-images.githubusercontent.com/36278229/144137141-04d270aa-c22a-4cc4-b02b-233d5fef7bff.mp4

In screen recording you can't see the problem very well because as soon as I switch focus the recording just records black for a couple seconds. I'm using OBS Studio with a display capture of the monitor. When I use a window capture the recording shows no flashing at all, although takes a few seconds to start recording the window after I've opened it.

https://user-images.githubusercontent.com/36278229/144137653-2ed25e93-93a8-4170-a208-64556214208c.mp4

With this video you can better see the flashing.

For the project in the videos I'm using following main.lua with no other files in Love2d 11.3, although I get the same problem with all other the projects I've tried:

function love.load()
    love.window.setMode(0, 0, {
        fullscreen = true,
    })
    font200 = love.graphics.newFont(200)
end

function love.draw()
    love.graphics.print('test',font200)
end

When using volume keys/mute to change volume the Windows media pop-up doesn't show when tabbed-in. Opening the Xbox Game bar using Win + G it does work, but shows this pop-up and refuses to screen record. When I press Win + Shift + S to screenshot the screenshot is always a few seconds or more delayed. If I then click escape and screenshot again it screenshots at the time of the last screenshot.

I'm using Windows 10 21H2 with a GTX 980, Nvidia driver version 496.76 (latest at the time of writing). I tried using SDL 2.0.18 instead of the one included in Love2d 11.3, but got the same results.

On my laptop I don't get any screen flashing at all. Windows volume control shows, Xbox game bar doesn't come up with that error and screen records correctly and screenshots are taken at the right time. Its GPU is an Intel UHD Graphics 615, with a 8100Y.

[MikuAuahDark]

I have same issue with 2 of my laptops:

1. With my old laptop (dual GPU), it only occurs if I set the rendering mode to integrated graphics, not nvidia GPU
2. With my current laptop (Ryzen APU), it only occurs if I set LOVE DPI scale to 100% explicitly.

Unfortunately, this is slime response in Discord:

yeah it just sounds like your graphics driver is switching to its internal exclusive fullscreen mode when it thinks it can (when it knows the game is covering the whole screen), but it doesn't handle app switching very well. not much love's source can change about that. the graphics driver probably has different codepaths for that for dx12 vs dx11 vs opengl vs dx9 etc

I found that using ANGLE prevents that issue from happening.

EDIT: I'm surprised no one actually reported this to SDL yet. I'll see if I can get a proper test case on weekend.

[FormularSumo]

Using ANGLE also resolved the issues for me, and for another couple of computers I tested on. Those computers were having variations of the problem, one has an RX 580 and the other Intel HD Graphics 2500 with a 3220T

[MikuAuahDark]

After further inspection, setting this to 0 prevents the issue. https://github.com/love2d/love/blob/cee8f8ae4854f4a7f7067b7a4b200e991a05c66f/src/modules/window/sdl/Window.cpp#L103

Although I'm not sure about the implications.

[RaniSputnik]

@MikuAuahDark I don't know too much single buffering vs double buffering but it sounds like you should test this with a moving image. It may very well be worse.

Single buffering, is actually all the drawing instructions in the window execution, is directly in the window drawing, such a drawing efficiency is relatively slow, if the use of a single buffer, and the computer is relatively slow, the screen will blink. double buffering, the actual drawing instruction is completed in a buffer, here the drawing is very fast, after the drawing instruction is completed, and then through the exchange of instructions to the completed graphics immediately displayed on the screen, which avoids the appearance of incomplete drawings, and high efficiency. In general, OpenGL drawings are double-buffered, and a single buffer is typically used only to display a single, non-dynamic image.