Multi-viewports rendering artifacts with OpenGL backend on 1.86

[inanevin]

Version/Branch of Dear ImGui:

Version: Dear ImGui 1.86 (18600)
Branch: docking
#1542

Back-end/Renderer/Compiler/OS

Operating System: Windows 10 20H2
GLFW: 3.3.6

Relevant Config:
IMGUI_HAS_VIEWPORT
IMGUI_HAS_DOCK
io.ConfigFlags: 0x000000441
DockingEnable
ViewportsEnable
io.ConfigViewportsNodecoration
io.BackendFLags: 0x00001406
PlatformHasViewports
RendererHasViewports

** Issue **

Superb work on the library, been using it for couple years now without any problems. Recently, I have decided to enable multi-viewports support for my app, seeing how the docking branch has progressed so far. Unfortunately, the feature seems to mess up the whole IMGUI window rendering [see the screenshots below] and it is indeterministic as far as I can test so far.

I have thought this is some sort of a render target synchronization issue and might be due to my window creation & rendering pipeline, or my modifications to the Dear ImGui library (been using it in my custom engine), so I decided to download the latest docking branch 15b4a06, build the glfw3 + opengl3 demo and give it a try. Still the same issue persists.

Only change to the demo source code was simply creating 2-3 more windows with only a text within. Initially nothing is wrong, docking and viewports work. But when one starts to dock windows around, sometimes out of nowhere the screenshot below happens. This is all within the primary monitor, when testing the viewports on secondary monitor more problems seem to occur, but that's a place for another issue.

This is not a major problem for my current development, however it would have been a nice to have this feature in a stable manner, just like other parts of the library.

*** EDIT

Enabling transparent payload seems to help initially, but the issue comes back after playing with the demo for some time.

Screenshots/Video

Significant timestamps: 00:06 & 00:30

viewports_v.mp4

[ocornut]

First time I see that.

Can you:

• download 1.85 and see if it also happens? (we made changes to GL3 backend recently)
• try with DX11 and some other backends?
• specify the GPU it is using and drivers versions

Thank you.

[inanevin]

First time I see that.

Can you:

• download 1.85 and see if it also happens? (we made changes to GL3 backend recently)
• try with DX11 and some other backends?
• specify the GPU it is using and drivers versions

Thank you.

Alright made some more tests, first of all, this "dock preview jittering" occurs on all OpenGl backends, 1.85 & 1.86, SDL & GLFW

I mention this because this jittering was mostly the sign that the rendering was about to break when testing on 1.86.

• 1.85 OpenGL + GLFW seems to work fine, tested about 5-6 minutes, no rendering mess up, only the preview node jitter. Going to test 1.85 in my own engine when I have the time.
• 1.86 OpenGL + GLFW, as you know, breaks sometimes right away, sometimes after docking couple windows around.
• 1.86 OpenGL + SDL, jittering + breaks rendering.
• 1.86 DirectX 11, 12 - No jittering, no rendering problems, smooth as butter.
• GPU: RTX 2070 - Driver: v472.39 - Same problem on both Studio & Game Ready drivers.

Some additional info:

• I feel like this is more of an OpenGL backend issue rather than GLFW, since SDL had the same problem as well.
• I work with +2 monitors apart from the primary laptop monitor, disconnected them just in case, problem persists.
• Both Debug & Release configs, both Win32 & x64 platforms have the same issue.
• Sometimes the issue shows itself as a constant flickering on the window currently being dragged. This flickering can turn into rendering breaking, or two can happen at the same time.
• Sometimes when a window is messed up, docking it in place solves the problem, but sometimes the artifacts are permanent, like a non-cleared color buffer.
• When I delete .ini file & start the app with default window positions, it seems to work OK for couple of "docks", but when I close the app once the rendering broke, since the .ini would be saved, as soon as I open the app some viewports start outside and rendering breaks on them immediately.

[ocornut]

Thank you!

The jittering is a completely different issue, see #2361. I believe the way t solve it would be to create a temporary, front-most, transparent viewport to render those elements (which would requires to expand on the work #2766 (see other linked issues). As you suggested/found, io.ConfigDockingTransparentPayload was designed a workaround for this issue (only rendering the target box on the target viewport, and making the source fully transparent).

The rendering artifacts however are quite problematic. Along with #4825 this looks like a second regression caused by the change made for #4468... looks like we need to reopen #4468.

[ocornut]

Just to confirm we understand this properly, on latest can you try editing imgui_impl_opengl3.cpp
Remove:

        GLsizeiptr vtx_buffer_size = (GLsizeiptr)cmd_list->VtxBuffer.Size * (int)sizeof(ImDrawVert);
        GLsizeiptr idx_buffer_size = (GLsizeiptr)cmd_list->IdxBuffer.Size * (int)sizeof(ImDrawIdx);
        if (bd->VertexBufferSize < vtx_buffer_size)
        {
            bd->VertexBufferSize = vtx_buffer_size;
            glBufferData(GL_ARRAY_BUFFER, bd->VertexBufferSize, NULL, GL_STREAM_DRAW);
        }
        if (bd->IndexBufferSize < idx_buffer_size)
        {
            bd->IndexBufferSize = idx_buffer_size;
            glBufferData(GL_ELEMENT_ARRAY_BUFFER, bd->IndexBufferSize, NULL, GL_STREAM_DRAW);
        }
        glBufferSubData(GL_ARRAY_BUFFER, 0, vtx_buffer_size, (const GLvoid*)cmd_list->VtxBuffer.Data);
        glBufferSubData(GL_ELEMENT_ARRAY_BUFFER, 0, idx_buffer_size, (const GLvoid*)cmd_list->IdxBuffer.Data);

Replace with

        glBufferData(GL_ARRAY_BUFFER, (GLsizeiptr)cmd_list->VtxBuffer.Size * (int)sizeof(ImDrawVert), (const GLvoid*)cmd_list->VtxBuffer.Data, GL_STREAM_DRAW);
        glBufferData(GL_ELEMENT_ARRAY_BUFFER, (GLsizeiptr)cmd_list->IdxBuffer.Size * (int)sizeof(ImDrawIdx), (const GLvoid*)cmd_list->IdxBuffer.Data, GL_STREAM_DRAW);

And confirm that does fix the problem for you?

(basically undoing the meaningful part of 389982e)

OpenGL is a mess...

[inanevin]

Just to confirm we understand this properly, on latest can you try editing imgui_impl_opengl3.cpp Remove:

        GLsizeiptr vtx_buffer_size = (GLsizeiptr)cmd_list->VtxBuffer.Size * (int)sizeof(ImDrawVert);
        GLsizeiptr idx_buffer_size = (GLsizeiptr)cmd_list->IdxBuffer.Size * (int)sizeof(ImDrawIdx);
        if (bd->VertexBufferSize < vtx_buffer_size)
        {
            bd->VertexBufferSize = vtx_buffer_size;
            glBufferData(GL_ARRAY_BUFFER, bd->VertexBufferSize, NULL, GL_STREAM_DRAW);
        }
        if (bd->IndexBufferSize < idx_buffer_size)
        {
            bd->IndexBufferSize = idx_buffer_size;
            glBufferData(GL_ELEMENT_ARRAY_BUFFER, bd->IndexBufferSize, NULL, GL_STREAM_DRAW);
        }
        glBufferSubData(GL_ARRAY_BUFFER, 0, vtx_buffer_size, (const GLvoid*)cmd_list->VtxBuffer.Data);
        glBufferSubData(GL_ELEMENT_ARRAY_BUFFER, 0, idx_buffer_size, (const GLvoid*)cmd_list->IdxBuffer.Data);

Replace with

        glBufferData(GL_ARRAY_BUFFER, (GLsizeiptr)cmd_list->VtxBuffer.Size * (int)sizeof(ImDrawVert), (const GLvoid*)cmd_list->VtxBuffer.Data, GL_STREAM_DRAW);
        glBufferData(GL_ELEMENT_ARRAY_BUFFER, (GLsizeiptr)cmd_list->IdxBuffer.Size * (int)sizeof(ImDrawIdx), (const GLvoid*)cmd_list->IdxBuffer.Data, GL_STREAM_DRAW);

And confirm that does fix the problem for you?

(basically undoing the meaningful part of 389982e)

OpenGL is a mess...

Yes I agree it's a mess, and yes this fixes the issue on my device, both on the demo and also on my engine, tested around 10 minutes, zero problems regarding the jittering (with io.ConfigDockingTransparentPayload) and the artifacts. It seems that it works well with various GLFW window settings, 3 monitors & an GL renderer doing works on multiple framebuffers. I have also tested with Intel HD 630 integrated card on my laptop, works pretty smooth. I know the issue still needs work, but seems like you are on the right track.

I'll let the viewports active on my engine, I do regular two-week check-ups on various other devices and systems, will let you know if I face the same problem on other types of environments, appreciate the amazingly quick help and cheers!

[ocornut]

Interestingly - and a good news somehow - I noticed this issue also happens on my home laptop, so I can repro and experiment somehow.

EDIT Annoyingly, two days later I cannot seem to be able to repro anymore :(

[inanevin]

Do you have an integrated graphics on your laptop? I have tried it with couple of work laptops as well, on the work laptops issue only occurs on integrated Intel UHD series graphics cards.

[parbo]

I have this problem too. It goes away if I force my app to use the discrete graphics card in the Windows graphics settings (I have a Dell XPS 15).

[piernov]

Been facing a similar issue introduced by 389982e . However it happens with NVidia GPU when using nouveau on Linux, and it is not specific to docking branch (which we do not use).

I am not sure if I should have opened another issue since the circumstances are different (hardware/software) even though the commit that introduced the issue is the same.

EDIT: tracked at #5127

[PathogenDavid]

I am not sure if I should have opened another issue since the circumstances are different (hardware/software) even though the commit that introduced the issue is the same.

@piernov There's an issue specific to this issue with Nouveau here: #5127

Although the fact that this chance has caused similar glitches with two different drivers for two different GPU vendors makes me wonder if something about our usage pattern here is unusual.

[piernov]

My bad, I completely missed that one, reported over there instead.

[ocornut]

Based on reports like now I eventually settled on using varying codepath based on GPU vendors :(
In most cases the changes added in 389982e have been undoed. The codepath of 1.86 now only runs on Intel HD Gpu Windows.
Pushed: ca222d3

This sucks a bit, but hopefully it settles the problem :(

[ocornut]

Anyone affected by corruption issue,
could you cherry-pick this:
3a68146b
And see if you get anything printed?
EDIT 2022/09/27 merged 11f5be0 you can now uncomment #define IMGUI_IMPL_OPENGL_DEBUG.

(You may alter the fprintf statement to be whatever works best in your codebase)
Please also try with both values of UseBufferSubData (you may alter the if (bd->UseBufferSubData) check, turning it into true/false to try both paths). Please report with GPU/Drivers to ease parsing the information. Thanks!

[ocornut]

Could you also try both code path using GL_DYNAMIC_DRAW instead of GL_STREAM_DRAW ?

• Does it fix corruptions on setups that have them? (with/without UseBufferSubData)
• Does it fix leaks on setups that have them (with/without UseBufferSubData)
  Due to how your compact/minimal loader is generated, you may need to temporarily add:

#define GL_DYNAMIC_DRAW                   0x88E8

To the code. Thank you!

[parbo]

The state for me is that I can no longer reproduce the memory leak, even with the code as it was when I originally reported this. I guess the Intel driver has been updated to fix the problem.

The tearing issue is still there if UseBufferSubData is true, and not there if set to false.

GL_DYNAMIC_DRAW vs GL_STREAM_DRAW seems to make no difference.

Output from debug printouts:

GL_MAJOR_VERSION = 3
GL_MINOR_VERSION = 0
GL_VENDOR = 'Intel'
GL_RENDERER = 'Intel(R) UHD Graphics'

[ocornut]

Reverted the changes of #4468 with b8b0f9d, not using glBufferSubData() anymore.
PLEASE REPORT IF YOU STILL HAVE ISSUES AFTER TODAY.
I temporarily kept the alternative code path even though bd->UseBufferSubData is always false, allowing potential experiment shall new issues arises. Finger crossed this doesn't bite us back.