Support Dashed Lines

[ArekSredzki]

Thanks again for the fantastic library @epezent.

The main feature that I find to be missing is the support for plotting dashed lines instead of solid lines.
It'd be great for ImPlot to provide a setting for drawing dashed lines or for further control, configuring the dash and gap lengths.

Here is a visual example of what QwtPlot provides with Qt::DashedLine:

[ArekSredzki]

For more inspiration, see the QPen PenStyle enum

[epezent]

@ArekSredzki , I'd love to eventually support dashed lines! Unfortunately, I haven't come up with a great solution yet. A naïve approach of keeping a running tally of distance along the line, and splitting the line into multiple calls to the line renderer seems like a really bad idea. Omar suggests as much. I haven't given it a great deal of thought, but it would seem that the most performant approach would be to leverage either a texture or shader. I'm not graphically proficient enough to imagine how either would work with ImGuiDrawList without having to write platform dependent code (which won't be happening). Maybe @ocornut or @ShironekoBen have some ideas?

[ArekSredzki]

Thanks, @epezent for the speedy response as always :)
I've been thinking about this today and come to a similar conclusion, except I think it would be worthwhile to provide the naive solution as a stop-gap, with a sufficient warning about performance concerns.
Although the naive solution will certainly be suboptimal, I think it will function without significant issues in most use cases while enabling a feature that is commonly desired.

[ocornut]

We are currently working on standardizing backend systems to allow requesting backend for texture updates, resizes, partial updates. That will be a stepping one in enabling code to make more flexible use of texture data. Until then one issue is that there’s a infinite combination of dashing gaps and we can’t decide ahead which to store. Dashed lines won’t be trivial even with the texture change but at least you can upload a simple dash pattern into texture data and use that. Implementing single dashed line segment should be very easy then. Polyline will be more work. I don’t have ETA for any of it, but if you are interested in pushing for that it might be helpful to run your experiments. You can use AddCustomRect() to add texture data (currently awkwardly but it works) and try working on the primitives. I think we’ll want to be able to configure the initial offset in order to have animated/moving dashes too.

[epezent]

Thanks for the comments, Omar! We can take a look at how far we can get with textures and AddCustomRect and then let you know what backend features might be needed.

Do you have any similar plans for shaders? I feel that there could be major performance gains for ImPlot if we could do thick line triangulation in a shader (perhaps I'm wrong here), and that a shader might also handle the issues you mentioned above (dash/gap config, offset).

As @ArekSredzki suggested, it might also be worthwhile for us to at least test the naïve approach. Either way, I have more pressing features to attend to, so this might be a while into the future. @ArekSredzki, I'd be happy to offer some guidance if you'd like to work on a proof-of-concept PR for the naive approach we discussed.

[ArekSredzki]

Thanks guys. I'm excited to hear that ImGui's backends will be extended to have more capabilities to enable efficient rendering of these types of items. I wasn't sure if that was going to happen anytime soon 🎉

Adding to what @epezent suggested, if geometry shaders could be supported then we could do the thick line geometry computations on the GPU without too much effort.

In the meantime, I'll try to find some time to implement the naive approach. That said, work has been keeping me busy so I wouldn't complain if someone beats me to it :)

[dvj]

This paper explains the issues to think of when implementing dashed lines: http://jcgt.org/published/0002/02/08/paper.pdf

The shaders from the paper can be found at: https://github.com/rougier/JCGT-2014a/tree/master/shaders

[brenocq]

Context:

@ocornut: We are currently working on standardizing backend systems to allow requesting backend for texture updates, resizes, partial updates. That will be a stepping one in enabling code to make more flexible use of texture data.

@epezent: Do you have any similar plans for shaders? I feel that there could be major performance gains for ImPlot if we could do thick line triangulation in a shader (perhaps I'm wrong here), and that a shader might also handle the issues you mentioned above (dash/gap config, offset).

ocornut/imgui#4706 (comment): There's this ocornut/imgui#1118 but no particular update. You'd have to try to implement it on your own (you can use AddCustomRectRegular() to register space in the atlas texture and add your dashes in there.
The solution in ocornut/imgui#1118 will work, just be rather heavy (probably fine for ~100 segments though).

Hi @ocornut! I'm wondering if you have any new thoughts on how the dashed lines could be implemented using only the current ImGui API. I see that the ImGui backends currently support RenderDrawData and UpdateTexture, so I imagine that the texture approach you mentioned would be possible, but the shader approach wouldn't?

[ocornut]

Since 1.92, you can now indeed add and remove custom rectangles into the font atlas dynamically, even mid-frame, fill them with pixels you need, and query their UV back.

It’ll only work with backends supporting ImGuiBackendFlags_HasTextures.

If the texture data you need is rather static and may be uploaded once, you can do it during init or provide a helper function to do it early, and then it would be usable by older or non updated backends as well.

[ocornut]

so I imagine that the texture approach you mentioned would be possible, but the shader approach wouldn't?

Shader approach wouldn't be possible in a portable way indeed.

But I believe the texture based approach is better anyhow, although it is indeed more code.
Basically you would need code similar to the thick texture-based line drawing path that already exist (this is the code that uses the "pyramid" visible in the atlas texture, where each row is a unique thickness). The pyramid is prebaked entirely because dear imgui needs to support old backend not supporting ImGuiBackendFlags_HasTextures. But if your feature requires ImGuiBackendFlags_HasTextures to work, you would submit a texture chunk with the right thickness and one (or more) dash sequence, and use that for UV mapping.

I'd be potentially open to support that in ImDrawList down the line, but I can't really in the core library until we require ImGuiBackendFlags_HasTextures. So perhaps in a year-ish.