Is it expected behavior for the origin to move relative to lower left?

I am well aware this is a highly suboptimal circumstance to be asking for support in. I can’t post any substantial code as the project is proprietary, all the GUI stuff was written by a team member who is no longer with us, the actual OpenGL rendering for ImGUI was written by this team member and is heavily integrated into our graphics stuff so I couldn’t separate it out even if I was at liberty to post all the code, and I neither understand how that code works nor how ImGUI can possibly make a GUI without persistent objects representing each window, button, etc. Oh, did I mention we’re on a two-year-old version of ImGUI (1.53) because all our external dependencies are tied to specific Git versions and if I update there’s a good chance the whole thing will stop working? (I promise I’m a professional, really! :sweat: )

So I completely understand if the answer is “it’s your bug, not ImGUI’s”. I just want to make sure of this before I spend any more time trying to pull apart this codebase. Now that that’s out of the way…

I’m creating a window like this:
ImGui::SetNextWindowPos(ImVec2(20,20), ImGuiCond_Always);
ImGui::Begin(“Performance”, &windowOpen, ImGuiWindowFlags_AlwaysAutoResize
| ImGuiWindowFlags_NoSavedSettings
| ImGuiWindowFlags_NoMove
| ImGuiWindowFlags_NoInputs
| ImGuiWindowFlags_NoResize
| ImGuiWindowFlags_NoScrollbar);
ImGui::Text(“hello world”);
ImGui::End();
ImGui::Render();

The window is positioned at (20,20) from the upper left corner and renders just fine (it’s really running every frame, we’re updating the contents, it’s not actually “hello world”).

However, when I resize the application window, the ImGUI window remains at the position it currently is relative to the lower left corner. It’s as if the ImGUI origin separates from the upper left corner and moves up or down along the left edge of the application window, so that it’s in a constant position relative to the lower left corner. I would expect that if (20,20) is 20 pixels in X and Y from the upper left corner once, then it’ll be 20 pixels in X and Y from the upper left corner regardless of how the window is resized (the origin will stay in the upper left corner).

Is this expected behavior? Is this a well-known bug in this older version of ImGUI? Or have you never seen anything like this and it’s probably a bug in our renderer?

Thanks!

Edit: Window size changes in (w, h) here are being reported to ImGUI as follows:
auto io = ImGui::GetIO();
io.DisplaySize = ImVec2(w, h);
int display_w, display_h; //width/height including DPI, useful for Retina displays
glfwGetFramebufferSize(window, &display_w, &display_h);
io.DisplayFramebufferScale = ImVec2(
w > 0 ? ((float)display_w / w) : 0,
h > 0 ? ((float)display_h / h) : 0);
std::cout << "ImGUI new window size: " << io.DisplaySize.x << ", " << io.DisplaySize.y << “\n”;
std::cout << " scale: " << io.DisplayFramebufferScale.x << ", " << io.DisplayFramebufferScale.y << “\n”;
The printed outputs are the correct window size, and the scales are nearly always 1 though occasionally floating-point numbers like 1.0001f and 0.999f.

Updating is generally not too hard, as every breaking change has been documented, and I would strongly suggest updating at some point.

EDIT I suppose it depends of how much complex code you have. If you have very intricate/elaborate tools, it is possible that some things will subtly break and they will requires a little work from you (the changelog/api breaking changelog casn help).

If it looks scary you may update in two steps (e.g. 1.53 > 1.60 > 1.70) but honestly it shouldn’t be problematic. While you are it, after updating you may want to enable IMGUI_DISABLE_OBSOLETE_FUNCTIONS in imconfig.h temporarily and get rid of all old calls/names your code may still be using, so your code will be more future proof.

That’s the correct expectation. To be honest I can’t really think what the issue may be, nor do I recall a bug of that sort which have been present in 1.53.
You can call ImGui::ShowMetricsWindow() to inspect the actual window position and the value of each vertices and that should confirm that the positions are what you expect.

From there the only culprit left would be your rendering function, e.g. maybe look at how your rendering function is setting the viewport and project matrices?

-Omar

Hey, thanks for the response! I figured that would probably be the answer. I’ll dig into the rendering and also try ShowMetricsWindow(), and also try updating. I’ll post again if I can track down the issue to something more directly within ImGUI, though I suspect this won’t be the outcome.