Mesh size limitation

[wsphillips]

Hitting the limitation mentioned here: epezent/implot#30

Demo to reproduce here: https://github.com/wsphillips/CImPlot.jl/blob/master/demo/demo.jl
This attempts to plot 100k points, but can only display 16k at a time.

Issue raised because (supposedly) this is fixed within imgui itself (from discussion above):

If you plan to render several thousands lines or points, then you should consider enabling 32-bit indices by uncommenting #define ImDrawIdx unsigned int in your imconfig.h file, OR handling the ImGuiBackendFlags_RendererHasVtxOffset flag in your renderer (the official OpenGL3 renderer supports this). If you fail to do this, then you may at some point hit the maximum number of indices that can be rendered.

In the CImGui.jl OpenGL backend RendererHasVtxOffset seems to be set, so I'm not sure why it's still truncating...?

[Gnimuc]

I got a sinusoidal noisy wave. How could I know the number of points plotted?

Oops! Never mind. I just found the way to get the number, but it works normally on my machine:

[Gnimuc]

Issue raised because (supposedly) this is fixed within imgui itself (from discussion above):

If you plan to render several thousands lines or points, then you should consider enabling 32-bit indices by uncommenting #define ImDrawIdx unsigned int in your imconfig.h file, OR handling the ImGuiBackendFlags_RendererHasVtxOffset flag in your renderer (the official OpenGL3 renderer supports this). If you fail to do this, then you may at some point hit the maximum number of indices that can be rendered.

I'm pretty sure this has been fixed in #12. However, I only tested it on macOS, so there might be something wrong on other platforms.

[wsphillips]

The visible points will offset according to the plot limits. You're only displaying about 1000-2000 points in those screenshots. In the demo, each X-axis point has a delta of 0.01, so the truncation becomes visible when the X-axis range spans any range wider than ~16. You can modify X limits with click and drag or mousewheel while hovering the X-axis. Panning back and forth with more than 16k point range makes the truncation obvious.

[wsphillips]

For line plots, the argument can be made that displaying data ranges more than 1-2X your monitor's horizontal resolution is a waste (I plan to work around this for now by downsampling data). However, this might be a pain for other types of plots or more complex generic rendering in the future.

If it's not truly fixed by the backend implementation, the easiest alternative might be to include the macro/pre-processor definition mentioned in the readme when building (perhaps when we make the move to v1.76).

[Gnimuc]

The macro definition method is not recommended in ocornut/imgui#2591:

If you've been using 32-bits indices, I would appreciate if you try to revert back to 16-bit indices and use this feature (need to update your renderer).

The back-end implementation is ported from imgui's opengl3 implementation, it should work correctly(e.g. https://github.com/inkydragon/Jui.jl/blob/Fractal-demo/test/LargeMeshTest.jl#L52).

I didn't read the implot source code, but I guess the problem is likely due to it doesn't handle VtxOffset correctly when doing the line plot.

[Gnimuc]

When _VtxCurrentIdx passes 16k, it should be reset to 0 and add a new drawing command. It looks like implot does nothing about this.

[Gnimuc]

Should be fixed by epezent/implot#41.

[wsphillips]

The fix is now merged into implot (with a number of other optimizations). There was also a commit merged to imgui master that addresses the same issue (although I don't think it's entirely mandatory since (in my hands) local C++ builds using v1.76 imgui + latest implot can render high vertex plots without the culling). In either case, it looks like v1.77 imgui is nearing, so when that happens we should be good to go. Closing this issue since it appears to have been solved upstream.