Multiple main viewports / or no main viewport

[morgoth990]

Version/Branch of Dear ImGui:

Version: WP 177
Branch: docking

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_opengl3.cpp + imgui_impl_morgoth.cpp (custom implementation forked from sdl)
Compiler: Visual Studio 2019
Operating System: Windows 10 Professional

My Issue/Question:
My engine start in headless mode and support multiple windows but the imgui main window paradigm dont allow me to dock or move windows into the other engine windows.

At the moment I'have a patched version that seem to work, I've tried to manually call AddUpdateViewport function and the system works fine but there are some other changes to be done like:

• some checks on the PlatformWindowCreated bool to not exclude the viewports from processing
• exclusion from UpdatePlatformWindows:
  in my case with
  if (is_new_platform_window && viewport->PlatformHandle != NULL)
  but probably there is a better way to achieve that
• some asserts on non main viewports
• introduction of a defaultViewport in the context with correlate Set/Get methods to allow to render elements like main menu bars on a specific window

I'know the standard use case is with a single main window but I think this feature will not exclude a main window paradigma, is more like an additional support for viewports with a NULL ImGuiWindow and a set of function the user can call (AddUpdateViewport, SetDefaultViewport, GetDefaultViewport)

[ocornut]

Hello @morgoth990,

This has been discussed before and I like to support this mode of operation. I would be interested to see your changes (e.g. in the form of a repo or PR) for references. Likely won't be merged as-is but any extra reference will be useful. Someone actually submitted to me a codebase with similar change a year ago but it was made hastily with no git commits nor explanations for many changes and got essentially half lost :/

Two things come to mind:

• Reliance on GetMainViewport() will need to be reworked. Perhaps we need to rework/blur the lines between Viewport and Monitors in order to provide an abstraction that works with both use case. e.g. being able to retrieve a reference "default" origin.
• Some code assume that viewports[0] has the ImGuiViewportFlags_CanHostOtherWindows flag, and the use of that flag is probably a little ambiguous in some areas, may set to split the flag into multiple ones.

(Also, while technically completely unrelated, supporting this mode of operation will get us in territories where features such as #2749 will be highly desirable!)

[morgoth990]

I've forked and committed the changes here: morgoth990@beb1b3c

[ocornut]

Thanks for the details and comments. Not sure when we'll be able to look into it but this is going to be a good reference.

[ocornut]

We started backporting a very small bit of the viewport infrastructure to master and clarified the definition of viewport and main viewport specifically to allow this use case (intent being that GetMainViewport() is never NULL and may refer to a reference screen/monitor in the case of "no main viewport" mode).
https://github.com/ocornut/imgui/blob/master/imgui.h#L2723

But there's lots of work remaining to get to the end goal.

In the short-term I would suggest that @morgoth990 branch should remove the unnecessary renames to shorten the diff, since GetMainViewport() now conform to what GetDefaultViewport() does in their branch.

To answer your question....
It's presently a little difficult for us to receive help. More people are ok to put in the initial bit of work and publishing it is very helpful, but very rarely people have the energy/patience to follow through the full scope and use cases seriously. In my experience people tend to largely underestimate the steps required from going to a quick "commenting out this block and that block" to a sturdy and healthy opt-in design, while potentially involving both forward and backward compatibility in the mix. If you think you want to potentially pour 100+ hours at following the ramifications of this over multiple backends and OS we would consider guiding you through it. But often it takes too much time and energy for us to be guiding people through the yet unknown steps and it's not often a worthy investment as people seldomly stick around. So I've learned that either we end up doing it (taking advantage of all infos/code/pr/hacks published in issues) either we wait until someone unusually patient and meticulous goes through it in a way that is sufficiently convincing, but there's no magic here, someone will need to sit down and follow the many threads this can lead us into.

The specific problem with that feature is that it leads us into more backend work (e.g. for a start designing how common backends would interact with this), and backends notoriously means infinite maintenance. It's going to inevitably put to the front lots of issues with the existing viewport infrastructure (e.g. relation to z-ordering, focus and access to inputs), some of them being hindered by SDL/GLFW and potentially needing us to work on those libraries too or find workarounds.

I however see that it would be healthy to at least explore just enough of it to be able to nail the changes in the core library (several pointed by branch above) but if we don't provide solid support for our backends immediately we would eventually need to. So I don't mean to say this is particularly hard to solve but it needs to be looked with a holistic pairs of lens and right now I don't have the bandwidth for it. But I DO want to solve this eventually. Note that the more we head into this "desktopey app" world the more requests will come with it. One day you add headless startup the next day people want idle-mechanism across all backends etc.

As a general statement, absolutely not specific to this issue, aside from committing serious it to it, the other single best way to help Dear ImGui progress when using it at your work/company is to contact us and help us convince them to inject funding, as it allows us to keep the project afloat and hire focused people (Rokas has been helping part time for a long while now). At this very specific moment in 2021 dear imgui is sitting on a particularly precarious situation, so it's occasionally difficult for me to project myself into opening up to a larger set of usage scenario when I have no clue if I'll be able to pursue this next year. EDIT Blizzard saved the day once again!

[bvgastel]

Thanks for the quick and extensive reply. It is hard to be the long time maintainer of an open source project, I can imagine. I partly saw your reply coming, so after posting I tried to focus on the most important thing for me: an energy efficient mode. That is why I already removed my comment here.

I work at an university, so I don't think they will be able to support it financially. But I really do want to help Dear imgui. I don't now how it works out in the long run. This specific issue is a long term issue indeed. I can start maybe on a somewhat smaller issue like #2749, update it, and review/extend the PR. Maybe best to take this offline. May I contact you on Twitter directly?

[exuvo]

I have made multiple main viewports work on the latest docking branch with usage of ImGuiViewportFlags_OwnedByApp and ImGuiViewportFlags_CanHostOtherWindows instead of morgoths checking against PlatformHandle. Posting complete information here for others which want to do the same. Morgoths info was lacking a lot of details when i actually started to do this.

I have targeted multiple main viewports while always having a main viewport open and never closing that first one, which is enough for my use case. I have only modified glfw and vulkan to work but it should be fairly easy to adapt for other backends. Tested on linux with gcc as compiler. (I have not done any exhaustive testing for bugs).

Minimal ImGui core changes exuvo@58f6204
C++ version of imgui_impl_glfw https://github.com/exuvo/Aurora-C/blob/master/src/ui/imgui/imgui_impl_glfw.cpp
The changes to impl_glfw are one instance per main window, each containing:

bool isMainWindow; // true for first main window, false for new main windows after that
ImGuiViewport* viewport = nullptr; // ImGui viewport associated with this main window
GLFWwindow* g_Window;

the other things which are static in normal imgui_impl_glfw remain that way. Part of the normal imgui_impl_glfw init is only run when the main window is created via bool isMainWindow constructor parameter. If false we instead register a new viewport in ImGui with:

int x = 0, y = 0, w = 0, h = 0;
glfwGetWindowPos(g_Window, &x, &y);
glfwGetWindowSize(g_Window, &w, &h);
ImGuiViewportFlags flags = ImGuiViewportFlags_CanHostOtherWindows | ImGuiViewportFlags_NoAutoMerge | ImGuiViewportFlags_OwnedByApp | ImGuiViewportFlags_IsPlatformWindow;
void* pnt = this;
ImGuiID id = ImHashData(&pnt, sizeof(void*), 0);

viewport = ImGui::AddUpdateViewport(nullptr, id, ImVec2((float) x, (float) y), ImVec2((float) w, (float) h), flags);
viewport->PlatformHandle = (void*) g_Window;

Then in imgui_impl_glfw NewFrame we once again only do the normal things if isMainWindow is true. If false we run the exact same code as above to position the viewport of this extra main window correctly.

When creating a new main window, after creating a new imgui_impl_glfw instance i have to call ImGui_ImplVulkan_InitViewport(imgui_impl_glfw->viewport) too to set up some things that the vulkan backend expects to exist.

Now figuring out the rendering steps (this can be simplified if you only create ImGui windows from the main viewport):

1. Go thru all main windows and call their respective imgui_impl_glfw.NewFrame.
2. Call ImGui::NewFrame();
3. Go thru all main windows and render your normal stuff followed by ImGui::SetCurrentViewport(nullptr, (ImGuiViewportP*) imgui_impl_glfw->viewport); and then do your ImGui begin/text etc.
4. Call ImGui::Render();
5. Go thru all main windows and render each main windows ImGui viewport via:

ImDrawData* draw_data = ImGui::GetDrawData(imGuiGlfw->viewport);
ImGui_ImplVulkan_RenderDrawData(draw_data, command_buffer);

6. After rendering ImGuis draw data you can end the renderpass and submit to GPU.
7. Finally call ImGui::UpdatePlatformWindows(); and ImGui::RenderPlatformWindowsDefault(); for the platform windows.

With this i can drag ImGui windows between my programs main windows which is really nice.

-edit-
Commit to handle closing of new main windows exuvo@a0fe168

[JannesN]

@exuvo Any news on this one after a while? Does it run nicely? I am currently in the process of implementing your solution and it looks very promising to me!

[exuvo]

I have not been working much lately on my game where i use this, but it worked well in all my testing of it.