Window alpha blend issue when using GLFW_TRANSPARENT_FRAMEBUFFER (OpenGl3)

[SageMade]

Version: 1.73 (cb538fa)
Branch: docking

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_opengl3.cpp + imgui_impl_glfw3.cpp
Compiler: Visual Studio 2019 (MSVC)
Operating System: Windows 10 Pro (1809)

My Issue/Question:
When transparent framebuffers are enabled in GLFW (via GLFW_TRANSPARENT_FRAMEBUFFER window hint), imgui backgrounds do not properly alpha blend, and the underlying windows will bleed through the imgui windows, even when the backbuffer transparency is 1.

Expected result:

Actual result:

Suggested Resolution:
Change line 186 of imgui_impl_opengl3.cpp from:

    ...
    glEnable(GL_BLEND);
    glBlendEquation(GL_FUNC_ADD); // both rgb and alpha func is add
    glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
     ...

to

    ...
    glEnable(GL_BLEND);
    glBlendEquationSeparate(GL_FUNC_ADD, GL_MAX); // rgb is add, alpha is max
    glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
    ...

This fixes the issue, but I have not tested the potential side effects of this. In theory additive blending of alpha should work, there is probably something that I'm missing. Looking at the docs, the only way to go from 255 alpha to something lower is if As or sA is < 0). When doing a pixel debug in nsight, things start to make even less sense.

If you look at event 50, the alpha actually drops from 255 down to 241

Compare that to what the docs say, we should be getting:

Ar=As sA+Ad dA
sA = GL_ONE = 1
dA = GL_ONE_MINUS_SRC_ALPHA = (1 - 0.941...) = 0.059
Ar =240 * 1 + 255 * 0.059
Ar = 240 + 15
Ar = 255

I have the feeling that this is less of an ImGui issue and more of an issue with how GLFW or OpenGL handle transparent framebuffers (there's also an issue where a=0 does not blend properly with the underlying screen if any of the other channels are non-zero), but I need to do more digging.

As for the visual difference between additive and max, it looks OK to me, but then again I don't have any content underneath it yet:

I feel like I may be missing something else here, any suggestions?

Standalone, minimal, complete and verifiable example:

glfwWindowHint(GLFW_TRANSPARENT_FRAMEBUFFER, GLFW_TRUE);
window = glfwCreateWindow(w, h, "", nullptr, nullptr);

...
	
ImGui::CreateContext();
ImGuiIO& io = ImGui::GetIO();
io.ConfigFlags |= ImGuiConfigFlags_NavEnableKeyboard;
io.ConfigFlags |= ImGuiConfigFlags_DockingEnable;
io.ConfigFlags |= ImGuiConfigFlags_ViewportsEnable;

ImGui::StyleColorsDark();

...

ImGui::Begin("Example Bug");
ImGui::ColorEdit4("Easy to see with child controls", &color[0]);
ImGui::End();

[SageMade]

On further messing around, I think it would make more sense to change the blend function instead of equation, so:

glBlendFuncSeparate(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA, GL_ONE, GL_ONE_MINUS_SRC_ALPHA);

and keep glBlendEquation(GL_ADD)

This appears to have the same effect, and should have minimal impact on the appearance of UI's.

On another note, it looks like there is some more internal work to do to support transparent framebuffers. I may try my hand at a PR later, once I have some of the current issues resolved (biggest one is creating transparent windows and clearing properly for multiple viewports).

[ocornut]

Sorry @ShawnM427 for the late answer.

Went through a bunch of backends and examples yesterday.
Fixed this with bda12e5 and 6a161b8 (had seven related issues).

We will still need to work on better Backends and Multi-viewports support, so will keep #2766 open as current change don't fulfill all the ideas suggested by #2766. Will add more details there.