Multi-viewports and window z-order issues.

[cliffowen]

Version: 1.74
Branch: Docking

Back-ends: DirectX 11
Compiler: Visual Studio 2017, 141 toolchain
Operating System: Windows 10

There's appears to be some issues with depth sorting with the examples, specifically

example_win32_directx11.

Create a background dockspace, and I happened to maximize that window. Open up a couple other examples so you have windows to work with. It doesn't matter which windows.

Clipping the widget

Depth ordering

Thankfully, DX10 and DX12 as well as OpenGL 2 and 3 do not exhibit these issues so I'm hopeful it isn't a imgui issue but maybe more of a render pipeline issue. I also suspect the two issues are the same which is why they are both shown here.

SMCVE... it's just the example. No additional code..

Priority for me: Low. This is just for tracking and a someday fix.

[ocornut]

Hello,

This doesn't look related to DX11 at all, but rather to the multi-viewport system (where imgui window can be extracted out of the main viewport), so I am surprised you state that DX10 don't have the problem.

By default when multi-viewport are enabled, the imgui_impl_win32.cpp is configured to mark secondary windows as child of the main window so they'll always stay in front of the main window.

If you set io.ConfigViewportsNoDefaultParent = true; this parent<>child relationship won't be set between native secondary windows and the main window.

Otherwise this create a requirement that your secondary window have task bar buttons, and since Windows move window to the brong when clicked but NOT yet activated, it means we need to remove the ImGuiViewportFlags_NoFocusOnAppearing / SW_SHOWNA path in ImGui_ImplWin32_ShowWindow(), which is ok when no window decoration are visible...
It's a pretty complex problem and I would need to find a solution that degrade well for back-ends which are not supporting all the features of the imgui_impl_win32.cpp.

TL;DR; No obvious solution yet but I'm someday going to experiment with using io.ConfigViewportsNoDefaultParent = true as the default and the side-effects coming from that..

[cliffowen]

Wow, a reply in 15 minutes. That's Patreon worthy commitment. I'm just starting to experiment but very excited by what I've seen so far. DX10 may have problems stemming from this, but this specific problem was something I did not see when I was looking at DX10... and personally I'm not interested in DX10 for my example so I didn't spend much time with it. I hope you have enough info to repro the problem. I'm sure you'll find a solution.

[cliffowen]

Here is DX10... nice and responsive to clicks, the clicked window pops forward immediately. The center docking widget is weird but that's about it.

[ocornut]

See #1542 to understand what the “multi-viewports” feature is. It allows seamless extraction of an imgui window outside of your application window. If you make the example not fullscreen you’ll understand it more easily. In your situation the issue is triggered based on which imgui window are fully contained in the main application vs those which aren’t. The feature is a little experimental (and ambitious) but it is enabled by default in the examples/ in the docking branch, because enabling it is the best way to receive feedback. If inside the app you go to Demo > Configuration > and uncheck the configuration flags that enables “Viewports” you will see all windows become contained within the main application viewport again, and won’t have any z-ordering issue anymore.

[ocornut]

(And the reason is not happening in this DX10 gif is that all windows are contained within the boundaries of the main one so it doesn’t create new native windows)

[cliffowen]

Nailed it! 100% on both counts. I guess I had happened to NOT maximize the DX11 dockspace window. If I maximize, it doesn't happen. If I do not maximize but just make the DX10 window larger but straddles that boundary, it absolutely happened on DX10.

[ocornut]

Also note that if you want to use multi-viewports (which you might not even want to at the moment) using io.ConfigViewportsNoAutoMerge = true would enforce that every dear imgui windows creates it owns native window, which in turns which largely migitate the problem (at the cost of even more reliance on that system).