Poor Multi-Viewport Performance with Vulkan

[ekmett]

Version/Branch of Dear ImGui:

Version: 1.80 WIP Branch: viewport/docking

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_vulkan.cpp + imgui_impl_sdl.cpp Compiler: clang Operating System: OSX

My Issue/Question:

Using multiple viewports leads to pretty drastic slowdown when you have lots of little windows.

Standalone, minimal, complete and verifiable example:

To reproduce take the demo sdl2 + vulkan example, ensure multiple viewports is on, unclamp the framerate with IMGUI_UNLIMITED_FRAME_RATE then open the demo window and proceed down the menus:

Menu > Open Recent > More .. > Recurse.. > Open Recent > More.. > Recurse > Open Recent > More.. > Recurse.. > ...

As you build up more and more menu parts outside of the window, the framerate drops precipitously. In my case, 60fps plummets to <10fps, with just a few menus outside of the main window. Dropping quadratically? Without multiple viewports enabled, the framerate remains rock steady as I'd expect.

[ocornut]

I believe it’s a problem where every viewport is doing a swap and waiting for vsync. Vulkan specs are a bit of a mess and it probably depends on the driver, but i believe we should try to do a single synchronized swap with all swapchains, it seems possible in the vulkan api but haven’t tried yet. Because of how the ImGuiPlatformIO api is layed out it may need some reshuffling of that api to do it neatly but in the meantime we could hack things up to test if doing it this way fixes the problem on your machine.

[aiekick]

i have tested too on backends glfw and sdl2 i have the same issue, but the fps seem better on sdl2 than on glfw with same recursive menu opening

SDL2.14 / OPENGL 3 in debug on vs 2019 : => 49.6 fps GLFW3 (version of the repo) / OPENGL 3 in debug on vs 2019 : 28.6 fps

maybe there is a way for prevent the menu to quit a window when in viewport mode like what we have when not viewported

[uchytilc]

Presenting all swap chains in a single call does indeed fix this issue. This can be fixed with somewhat minor changes to the Vulkan backend code. Within ImGui_ImplVulkan_SwapBuffers instead of calling vkQueuePresentKHR the VkPresentInfoKHR struct should instead be pushed to a pending present list that will need to be added to ImGui_ImplVulkan_Data . Then when the main frame is ready to present instead of only presenting the main frame the main frame's VkPresentInfoKHR struct should also be provided to the pending present list, the list should then be presented via vkQueuePresentKHR and the present list should be reset for the next frame.