Odd animation-like autoresizing with Columns using ImGuiColumnsFlags_GrowParentContentsSize

[Folling]

(you may also go to Demo>About Window, and click "Config/Build Information" to obtain a bunch of detailed information that you can paste here)

Version/Branch of Dear ImGui:

Version: 1.72
Branch: docking

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_glfw.cpp + imgui_impl_opengl3.cpp
Compiler: CLang
Operating System: Arch Linux 64 Bit

My Issue/Question:
Having a window with an optional horizontal scrollbar, using the new columns-api with the GrowParentContentsSize flag causes a very odd behaviour.

Here's code that reproduces it on my system:

    ImGui::SetNextWindowSize(ImVec2{400, 400});
    if(ImGui::Begin("Column Bug Demonstration", nullptr, ImGuiWindowFlags_HorizontalScrollbar)) {
        ImGui::BeginColumns("test", 50, ImGuiColumnsFlags_GrowParentContentsSize);

        for (int j = 0; j < 50; j++) {
            ImGui::Text("%d", j);
            ImGui::NextColumn();
        }

        ImGui::EndColumns();
    }

Removing either the horizontal scrollbar from the window, or the flag from the columns fixes the issue.

and here's a video to show what it looks like:

[ocornut]

That's a side effect of the change in 1.71:

Columns: Fixed Columns() within a window with horizontal scrolling from not covering the full horizontal area (previously only worked with an explicit contents size).

It's not however incorrect (actually more correct than it used to be, just more strange). Combining both flags without setting a known contents size is kinda contradictory and creates a feedback loop. Columns use all the available width, and ImGuiColumnsFlags_GrowParentContentsSize is growing/requesting more width since that is permitted by the presence of the horizontal scrollbar.

If you use ImGuiWindowFlags_HorizontalScrollbar you need to either call ImGui::SetNextWindowContentSize(width, 0.0f) to decide of known width, or not exclusively use widgets that try to use whatever width is available while trying to grow that width.

Those problems will be much more naturally/easily solved with the upcoming Tables (~Columns V2) api.

(EDIT Please use github attachment for gif files and not external host, as requested by the contributing guidelines and issue template. If you use an external host you are actively preventing future users from understanding the context of your issue. Thank you!)

[Folling]

Sorry, I must've missed the embed in the contributing guideline!

And yeah, that actually does make a lot more sense 🤔
I don't know how many columns or the width of their content in advance, so I suspect I'll have to make an educated guess or precalculate using some measurements.

Thanks for the quick response!

[ocornut]

Generally if you enable horizontal scrolling the columns need to have a fixed (non-proportionally-stretching sizes) width. The column system currently only have "proportionally-stretching" columns.
Then your problem is to get a decent initial width for alll or individual columns. The Table system will handle that for you as well as offer manual options such as "fit all columns to contents".

I'm hoping the new table api will make it in a test branch in August and hopefully in master before end of September.

[Folling]

I figured out a good hack for my usecase: I calculate the size the item requires myself, and if it's larger than the current column's width, I reset the width to the item's value.
This looks almost flawless, though it needs to be wrapped into a separate class since the draw call has to be done after the calculation, otherwise things will be clipped through columns.

And I'm definitely looking forward to it! Though don't stress yourself, you've done amazing work on this project and enabled me and others to work on their dream-projects!

[ocornut]

Closing this as Columns are a legacy features and Tables now handle this better.