Open PeterJohnson opened 2 years ago
Hey Peter! Totally agree we should give PlotDigital
some love. PlotDigital
has bugged me for a long because of the way it implicitly plots y coordinates in pixel space, and the lack of control we offer over the way it stacks plots vertically. I'd either like to make it behave like the other plots (i.e. y values are in coordinate space), or add some generic functionality to ImPlot that allows the user to set an axis to plot in pixel space (e.g. like matplotlib).
Regarding you other points:
The input for this would be a X value, text to display, background color, and text color--although some of the examples below would require a boolean for a "empty" state (a middle line).
I have generally avoided cluttering PlotX
functions with additional buffers for per-element colors, text, etc. in an attempt to keep the API concise and maintainable. But obviously that is starting to limit us in more ways that one (e.g. see #298 and my comment there). I am beginning to lean toward adopting an optional buffering API (e.g. BufferColors(const ImVec4* cols, int count);
that would be called just before PlotX
. Would love some feedback in this regard!
Text is an odd one, and maybe a callback is best for this.
The output visually would look like some of the examples below.
Plot digital could take an ImPlotDigitalFlags
to specify the styling to be used (FYI, item flags is currently in the works for all plot types in #319)
Ideally it would also support getting hovered state to display extra information.
This is something we really need to implement API wide. I'm just not sure how to do it efficiently yet (both from a performance standpoint and the amount of new code I'd need to write).
Thinking more about how to do 292 generically, what if these labels were simply additional axes that have vertical placement (eg you can specify top and bottom, rather than having them always span the entire height of the plot like current axes do)? With the setup API it’s much more natural to add more axes. There’s some other benefits of this approach too in API space, e.g. it’s natural to plot multiple lines if desired on one of the vertically stacked axes, drag and drop and hover etc fall into the existing axes API, you can easily graph analog range next to digital without overlap, etc.
Re: #298, what about a AddDataColor(ImU32*, size_t stride)
, AddDataLabel(const char**, size_t stride)
etc (eg variants for ImVec4 color, sized strings)? Yes, the data would need to persist through the following Plot call, but because the Plot calls already support stride, this would enable arbitrary data structures on the user side that contain eg x,y,color,label and avoid the need for copying them into other buffers.
While the digital signal capability of LinePlot is nice, it would be very cool to have a more powerful version of it to display things like digital busses or states similar to a logic analyzer display. The input for this would be a X value, text to display, background color, and text color--although some of the examples below would require a boolean for a "empty" state (a middle line). The output visually would look like some of the examples below. Ideally it would also support getting hovered state to display extra information.
An enhancement similar to #292 would pair nicely with this, as seen in many of the below examples.