Too many vertices in ImDrawList using 16-bit indices

[ozlb]

Plotting in real time mode 4 channels (items) with PlotItemBufferPoint max_points at 4096 will crash after some time.. (around 128[s])
void AddDrawListToDrawData(ImVector<ImDrawList*>, ImDrawList): Assertion `draw_list->_VtxCurrentIdx < (1 << 16) && "Too many vertices in ImDrawList using 16-bit indices.

In order to solve the issue, is there any other solution than uncomment '#define ImDrawIdx unsigned int' line in imconfig.h." ?

[epezent]

It’s not something I’ve investigated, as I have been working with 32 bit indices. I think we’d need to implement some sort of culling scheme. As it is, there is no culling...every point is sent to the DrawList, even if it is outside the plot area. Seems like low hanging fruit, so maybe I can take a look. This of course won’t solve your issue if all 4x4096 points are in the plot area. If that’s the case, then it might be possible to decimate the data.

[epezent]

I added a simple culling solution. Line segments are only rendered if both endpoints are in the plot area. For every segment that is culled, 6 indices will be freed. Let me know if this helps at all.

e0b61c0

[epezent]

Could you also please try @ocornut's suggestion:

Since 1.71 (2019/06) it is possible for the back-ends to set ImGuiBackendFlags_RendererHasVtxOffset and support VtxOffset allowing for mesh larger than 64k vertices even with 16-bit indices.
Either way, you should coarse clip render item in your plotting system, ImDrawList doesn't do any clipping on CPU side.

ocornut/imgui#3067 (comment)

[ozlb]

I added a simple culling solution. Line segments are only rendered if both endpoints are in the plot area. For every segment that is culled, 6 indices will be freed. Let me know if this helps at all.

e0b61c0

Hi, the above solution is not working in my case. Same error:

void AddDrawListToDrawData(ImVector<ImDrawList*>, ImDrawList): Assertion `draw_list->_VtxCurrentIdx < (1 << 16) && "Too many vertices in ImDrawList using 16-bit indices. Read comment above"' failed.

Anyhow, performances are improved by this solution

[ozlb]

Could you also please try @ocornut's suggestion:

Since 1.71 (2019/06) it is possible for the back-ends to set ImGuiBackendFlags_RendererHasVtxOffset and support VtxOffset allowing for mesh larger than 64k vertices even with 16-bit indices.
Either way, you should coarse clip render item in your plotting system, ImDrawList doesn't do any clipping on CPU side.

ocornut/imgui#3067 (comment)

This solution at least is "fixing" the assert check and application is not quitting, but the results are poor.
This is how should be

This is when I zoom out

[epezent]

Oh wow, that's no good! Then it seems that the only real path forward is to decimate data. I can think of a couple ways of doing this, each with their pros/cons. I'll ponder the issue and report back later.

For now, I would suggest either:

1. reducing your history duration (e.g. 10 seconds, not 60)
2. slowing down your feed rate (e.g. push a new data point only every N frames)

[epezent]

The other obvious answer is to just use 32 bit indices, but I assume there's a reason you can't do that (is this an OpenGL2 limitation?)

[ozlb]

The other obvious answer is to just use 32 bit indices, but I assume there's a reason you can't do that (is this an OpenGL2 limitation?)

Thanks, if this is the solution (or "workaround") I will try to use 32 bit indices.

There is another small issue (off topic): when you interact with plot are (zoom and pan) it looks like it's missing focusing of the window. I mean that if there is another window on top and you interact with plot, focus remain on the window on top.

[ocornut]

Make sure your renderer actually does handle the VtxOffset field, not just set the flag claiming it handles it.

Use the Metrics window to confirm that your output it what you think it is and your clipping works as intended.

PS: Lines with >1.0f thickness are more vertex expensive than line with ==1.0f thickness. However a change coming soon to imgui will reduce the cpu and vtx cost of both either way. Neither should be a bottleneck for you, you should just handle VtxOffset to allow large meshes with 16-bit indices.

[epezent]

@ozlb, I can confirm that mahi-gui, which uses the official ImGui OpenGL3 renderer that supports VtxOffset, works perfectly fine with 16-bit indices. As you can see in the example below, it's having no issues with over 600k indices. I tested this in Release and Debug mode.

Therefore, I would suggest you address the VtxOffset issue with your rendering backend as @ocornut suggests. I will leave this issue open as a reminder that data decimation needs to be added at some point (if for no other reason than performance).

@ocornut, I think I'm already drawing plot lines as efficiently as possible since I bypass the built-in drawing functions. I adapted the latter half of AddPolyline (the non-AA implementation) for my code, which uses 4 verts and 6 indices for every individual line segment. Is this the best we can currently do? I'm excited to see the future change you are referring to! Anywhere I can read up on this?

[ozlb]

I will try to study and try to understand what should be done in order let it work properly.
I'm sorry...

[ozlb]

ocornut/imgui#3067 (comment)

Thanks!

Anyhow there is still present the "focusing" bug, could you please check or give an advise on how to fix?