Table column sort icon in wrong place

[goossens]

Version/Branch of Dear ImGui:

Version: 1.86
Branch: Unmodified release

Back-end/Renderer/Compiler/OS

Back-ends: Custom GLFW with BGFX
Compiler: Xcode
Operating System: MacOS Big Sur 11.6.2

My Issue/Question:

Depending on the flags passed to create a table, the sort icon in the last column is rendered in the wrong place.

• The sortable table demo uses ImGuiTableFlags_Resizable , ImGuiTableFlags_BordersOuter, ImGuiTableFlags_BordersV and ImGuiTableFlags_NoBordersInBody. This renders correctly.
• By removing the border (i.e. remove the ImGuiTableFlags_BordersOuter, ImGuiTableFlags_BordersV and ImGuiTableFlags_NoBordersInBody flags), the sort icon in the last column shifts a few pixels to the right.
• By also removing the ImGuiTableFlags_Resizable flag, the sort icon in the last column shifts out of view.

Screenshots/Video

XXX (you can drag files here)

Standalone, minimal, complete and verifiable example: (see #2261)

Change lines 5054-5057 in imgui_demo.cpp from:

        static ImGuiTableFlags flags =
            ImGuiTableFlags_Resizable | ImGuiTableFlags_Reorderable | ImGuiTableFlags_Hideable | ImGuiTableFlags_Sortable | ImGuiTableFlags_SortMulti
            | ImGuiTableFlags_RowBg | ImGuiTableFlags_BordersOuter | ImGuiTableFlags_BordersV | ImGuiTableFlags_NoBordersInBody
            | ImGuiTableFlags_ScrollY;

to:

        static ImGuiTableFlags flags =
           ImGuiTableFlags_Reorderable | ImGuiTableFlags_Hideable | ImGuiTableFlags_Sortable | ImGuiTableFlags_SortMulti
            | ImGuiTableFlags_RowBg
            | ImGuiTableFlags_ScrollY;

[ocornut]

I can confirm the bug. In the end it is due to the _PadOuterX, _NoPadOuterX, _NoPadInnerX flags which happens to have different default based on the flags mentioned above.

By toying with flags in the "Advanced" demo + shift-clicking columns to see arrows in all columns we can visualize the issue better.

Thanks for reporting!

[ocornut]

I won't have time to be fixing this 100% right away.
It's a little complicated due to how TableGetCellBgRect() works and the padding system. There are good reasons why it is setup this way, but I believe TableGetCellBgRect() probably should be reworked.

In TableGetCellBgRect() at first glance this appears to work:

    x1 = ImMax(x1, table->BgClipRect.Min.x);
    x2 = ImMin(x2, table->BgClipRect.Max.x);
    x1 = ImMax(x1, column->ClipRect.Min.x);
    x2 = ImMin(x2, column->MaxX);

Which can also remove some code in TableEndRow()
But I think this willneed further inspection.

[ocornut]

Pushed a fix for this.

Another issue: note for future myself

There's another bug also related to how TableGetCellBgRect() function. In the drawing code in TableEndRow() when it applies horizontal clipping to avoid rendering highlight crossing frozen boundaries (cell_bg_rect.Min.x = ImMax(cell_bg_rect.Min.x, column->ClipRect.Min.x) and cell_bg_rect.Max.x = ImMin(cell_bg_rect.Max.x, column->MaxX); this accidentally undo the padding that TableGetCellBgRect() attempt to add (added by 1731ae5)). As a result in that situation with PadOuterX + NoPadInnerX, the BG highlight on a left-most and right-most cell will look incomplete:

(Right now I commented the padding in TableGetCellBgRect() as it is undone anyway. I think it should be reintroduced using OuterPaddingX and not CellPaddingX1/CellPaddingX2 as 1731ae5 did).

It's not probably that simple in reality, need to toy with Demo>Tables>Padding because I imagine there are varying expectation for where that boundaries should be depending on use and how it interact with merging of draw commands based on submitted contents, so I'll leave that for later.