What's wrong
CheckAndHandleContextChange() (ImGui.App/ImGuiApp.cs, ~line 2618) is called on every window resize/move (RemapCanvas) and is documented as auto-reloading textures on GL context change. It compares ImGui.GetCurrentContext().Handle against a cached currentGLContextHandle, and calls ReloadAllTextures() when they differ. But ImGui.GetCurrentContext() returns the ImGui context pointer, not the OpenGL context/device — ImGui.CreateContext() is called exactly once, in ImGuiController.Init(), and never again during the app's life. Nothing else in the codebase changes what ImGui.GetCurrentContext() returns (verified ImGuiExtensionManager.cs: ImNodes/ImPlot maintain their own separate contexts and never call ImGui.SetCurrentContext).
Why it matters (failure scenario)
newContextHandle != currentGLContextHandle is never true in real operation, so ReloadAllTextures() is effectively dead code. A real OpenGL context invalidation — a laptop with hybrid/switchable graphics moving the window to a monitor driven by a different GPU, a driver reset, or resuming from sleep on some Linux/NVIDIA setups — recreates the underlying GL context while the ImGui context handle stays identical. Every previously uploaded texture id in the Textures dict now references a deleted/garbage GL texture name on the new context, but the detector never fires, so every image loaded via GetOrLoadTexture renders blank/black/garbage for the rest of the process — silently, with no error and no way to self-heal short of an app restart, contrary to the documented "auto-cleanup on context change" behavior.
Suggested fix / acceptance criteria
Detect the actual GL context instead of the ImGui context — e.g. compare a real context identity Silk.NET exposes, or a GL-side marker set right after gl is (re)created in the window-load handler — rather than ImGui.GetCurrentContext().Handle. Add a regression test that swaps the mock IGL/GL context and asserts ReloadAllTextures fires.
What's wrong
CheckAndHandleContextChange()(ImGui.App/ImGuiApp.cs, ~line 2618) is called on every window resize/move (RemapCanvas) and is documented as auto-reloading textures on GL context change. It comparesImGui.GetCurrentContext().Handleagainst a cachedcurrentGLContextHandle, and callsReloadAllTextures()when they differ. ButImGui.GetCurrentContext()returns the ImGui context pointer, not the OpenGL context/device —ImGui.CreateContext()is called exactly once, inImGuiController.Init(), and never again during the app's life. Nothing else in the codebase changes whatImGui.GetCurrentContext()returns (verifiedImGuiExtensionManager.cs: ImNodes/ImPlot maintain their own separate contexts and never callImGui.SetCurrentContext).Why it matters (failure scenario)
newContextHandle != currentGLContextHandleis never true in real operation, soReloadAllTextures()is effectively dead code. A real OpenGL context invalidation — a laptop with hybrid/switchable graphics moving the window to a monitor driven by a different GPU, a driver reset, or resuming from sleep on some Linux/NVIDIA setups — recreates the underlying GL context while the ImGui context handle stays identical. Every previously uploaded texture id in theTexturesdict now references a deleted/garbage GL texture name on the new context, but the detector never fires, so every image loaded viaGetOrLoadTexturerenders blank/black/garbage for the rest of the process — silently, with no error and no way to self-heal short of an app restart, contrary to the documented "auto-cleanup on context change" behavior.Suggested fix / acceptance criteria
Detect the actual GL context instead of the ImGui context — e.g. compare a real context identity Silk.NET exposes, or a GL-side marker set right after
glis (re)created in the window-load handler — rather thanImGui.GetCurrentContext().Handle. Add a regression test that swaps the mockIGL/GL context and assertsReloadAllTexturesfires.