Clipper with many entries is triggering an assert related to ItemsHeight (Floating Point issues)

[DimitriFourny]

Hello,

I am using ImGuiListClipper in a table with 0x1eea802 elements. In don't do any fancy things, just putting text in each column.
Everything is working well except if I scroll in the middle of the table where I trigger an assert:

IM_ASSERT(ItemsHeight > 0.0f && "Unable to calculate item height! First item hasn't moved the cursor vertically!");

Because I don't have this problem with less elements, I guess it could be an integer overflow inside ImGui however I don't have a good understanding about how table->RowPosY1 and table->RowPosY2 are calculated.

Do you have an idea how to fix it please? Thank you.

OS: macOS Big Sur

[DimitriFourny]

I have done an easy fix for the moment by fixing the clipper items_height, switching from

  ImGuiListClipper clipper(0x1eea802);

To:

  ImGuiListClipper clipper(0x1eea802, 10.0f);

[ocornut]

I believe this has nothing to do with Tables, it's a problem with cursor positioning, Same as #3609.

We use float for all positions., although we only need unit precision (+1/-1) for vertical axis, floats can only guarantee it up to 16777216.0f aka 986895 lines with a typical default line height of ~17 (13 font + 4 spacing), and less lines with a larger fonts.

Everything is working well except if I scroll in the middle of the table where I trigger an assert:

Your number of lines (0x1eea802 = ~32 millions) is largely above that limit, and I believe things don't actually work well from ~1 millions. Going from 1 to 32 merely reduce precision down enough to cancel out the line height.

I don't have a good solution/answer to that problem presently, but UX wise I don't think it is meaningful for the user to make 32 millions entries available. Although the clipper aim to make large amount scrollable, there's a point where it doesn't make sense. Consider virtualizing the display, displaying items in chunks or or exposing more filters.

[ocornut]

I have done an easy fix for the moment by fixing the clipper items_height, switching from
ImGuiListClipper clipper(0x1eea802);
To:
ImGuiListClipper clipper(0x1eea802, 10.0f);

I must add that will be merely avoid the assert your encountered, but scrolling and layout are likely to be severely impacted by the loss of the precision either way.

[DimitriFourny]

Consider virtualizing the display, displaying items in chunks or or exposing more filters

I think I will do that in consequence, thank you very much for your quick answer!

[ocornut]

I have pushed variety of tweaks/fixes to improve this from multiple angles.
It's a bit fragile but basically in the situation where a very large range window always use the clipper, things will tend to work much better into higher range. I am not considering this a full fix.

With those changes, e.g. in the Tables>Advanced demo

• One million items now works without an issue
• Ten millions items works with a small offset but not juggling or jumping around.

a76bc52 Clipper: store initial precision loss and apply delta in clipper.

027a7ba Clipper: use line size instead of cursor comparison when ranges are large.

6e141a9 Internals: made ScrollbarEx() use ImS64 to facilitate use with larger ranges (not fully tested)
This is mostly to allow people reusing that code for custom scrollbars.

(+ unrelated fixed a small bug while doing this 926addb and 20e040c)