ImGuiConfigFlags_NavEnableGamepad can cause enormous slowdown when application first starts

[hatfield-c]

Version/Branch of Dear ImGui:

Version 1.91.3, Branch: master

Back-ends:

imgui_impl_glfw.cpp + imgui_impl_vulkan.cpp

Compiler, OS:

Windows 10 + MSVC 2022

Full config/build information:

Dear ImGui 1.91.3 WIP (19121)
--------------------------------
sizeof(size_t): 8, sizeof(ImDrawIdx): 2, sizeof(ImDrawVert): 20
define: __cplusplus=199711
define: _WIN32
define: _WIN64
define: _MSC_VER=1941
define: _MSVC_LANG=202002
--------------------------------
io.BackendPlatformName: imgui_impl_glfw
io.BackendRendererName: imgui_impl_vulkan
io.ConfigFlags: 0x00000003
 NavEnableKeyboard
 NavEnableGamepad
io.ConfigInputTextCursorBlink
io.ConfigWindowsResizeFromEdges
io.ConfigMemoryCompactTimer = 60.0
io.BackendFlags: 0x0000000E
 HasMouseCursors
 HasSetMousePos
 RendererHasVtxOffset
--------------------------------
io.Fonts: 1 fonts, Flags: 0x00000000, TexSize: 512,128
io.DisplaySize: 1280.00,720.00
io.DisplayFramebufferScale: 1.00,1.00
--------------------------------
style.WindowPadding: 8.00,8.00
style.WindowBorderSize: 1.00
style.FramePadding: 4.00,3.00
style.FrameRounding: 0.00
style.FrameBorderSize: 0.00
style.ItemSpacing: 8.00,4.00
style.ItemInnerSpacing: 4.00,4.00

Details:

I have had an intermittent issue for a few weeks now where Dear ImGUI will show a blank window for 30 seconds or more, when typically the window can otherwise show up in less than a second. Once the 30 seconds has passed and the window successfully renders for the first time these problems disappear. This seems to be more frequent when I accidentally cause the program to crash during other development activities, and starting today the issue is now constant and unceasing. Previously a computer restart could fix the error, but not anymore.

After some digging, I traced the problem to the function ImGui_ImplGlfw_UpdateGamepads() inside the file imgui_impl_glfw.cpp at line 784, which contains the following line of code: if (!glfwGetGamepadState(GLFW_JOYSTICK_1, &gamepad)) If I place a return; statement before this line of code, the application window renders just fine without issue.

I believe the issue is related to how glfw does input polling for gampads. I tried calling glfwJoystickPresent(GLFW_JOYSTICK_1) as a test, and it also causes the same 30 second delay that happens with glfwGetGamepadState(GLFW_JOYSTICK_1, &gamepad)

After the 30 second start up time and the first successful render, ImGui_ImplGlfw_UpdateGamepads() can be called every frame without issue or slowdown (I'm getting 170 fps right now).

The issue can be avoided by ensuring you do not add the ImGuiConfigFlags_NavEnableGamepad flag to the io->ConfigFlag variable. While I am mainly submitting this issue for the benefit of others facing this bug, I do feel further investigation is warranted. This extra io config flag is included by default in a lot of tutorials. Furthermore, adding this flag should not result in such a dramatic slowdown. Ideally ImGUI should take action to prevent this error from occurring.

I have tried connecting a gamepad (Xbox One controller via bluetooth) and then running the application. The issue persists regardless of whether or not a gamepad is present.

Screenshots/Video:

Minimal, Complete and Verifiable Example code:

IMGUI_CHECKVERSION();
ImGui::CreateContext();

ImGuiIO* io = &(ImGui::GetIO());
this->io = io;
this->io->ConfigFlags |= ImGuiConfigFlags_NavEnableKeyboard;
this->io->ConfigFlags |= ImGuiConfigFlags_NavEnableGamepad;

[hatfield-c]

Previously I've (sometimes) been able to get the error to trigger by clicking the "Stop Debugging" button (the red square) in Visual Studio Community 2022. The next time I compile and run the code in Debug mode for x64, the issue will (sometimes) start. I had a hard time getting this behavior to reliably work, and now that the issue is permanent for me now I have no way of re-testing this.

[ocornut]

Well as you pointed out this seems like an issue with GLFW, not with Dear ImGui. Have you tried updating GLFW? Otherwise perhaps report the issue there.

[ocornut]

This extra io config flag is included by default in a lot of tutorials. Furthermore, adding this flag should not result in such a dramatic slowdown. Ideally ImGUI should take action to prevent this error from occurring.

Well the thing is that this hasn't been reported before, so it may be an issue to your GLFW version or to your setup (some random drivers or software interfering). It's hard to tell. But it's definitively not the norm. I think you should first try to update GLFW, then open an issue on GLFW repository to investigate this further. It's likely they are going to ask you to provide extra information, such as e.g. tracing what's happening during this long stall. If you can break several times in a row in a debugger you may be able to see which piece of code/DLL is taking that time.

Please also make sure this is not just visual studio debugger choking on downloading symbols for new DLL being used. Normally this happens once in a while only, but I wouldn't rule a specific issue where it would keep loading downloading them everytime.

Sorry I have to close this. Unless proven that it is common issue that would affect other users, I don't think it's imgui_impl_glfw's job to design a workaround.