Visualisation Improvement ideas/fixes

[sergeyn]

1.) Minor ticks should not suddenly become major ticks, but gradually blend into major ticks. New minor ticks should blend in out of completely transparent ones. This will look much nicer when you do zooming, especially very rapid zooming. The point is not to have sudden changes in an image
2.) Add very mild animation on zooming - instead of sudden changes in zoom, zoom in gradually, starting at very fast speed, and slowing down when reaching zoom target, play the whole animation within 0.5-0.8second so it is still as sharp and responsive and not annoying. Also put it on a flag
3.) When zooming in, amount of digits for each tick grows and at some point they start to overlap.

I suggest skipping outputting text for ticks which will overlap with previous tick, with preference for major ticks of course.

[ozlb]

#1 What if instead we made the edges and corners of Query dragable/resizable after it is created? If the query was initially created using the Shift key (to expand vertical), then it would be the exact same behavior as far as I can tell. It also has the added benefit of working in the Y direction when needed. I'd just rather not have two similar tools to manage and upkeep.

I will re-trigger Query improvements, since I'm still updating my own local version with my "beloved" QueryX and main reason is that for my needs Query is not covering:
- resizing: Query cannot be resized or I'm not able to do it (as per @epezent post here above)
- lock on x or y expansion: when expanded, Query dragable in all directions I think it's something non needed: it should drag only horizontally if expanded vertically and vice-versa. It will be nice option to re-scale based on x axis range changes if expanded vertically.
- show/hide API: actual 'ImPlotFlags_Query' can condition only the user interaction but I would like to control the visibility. Actually about this, there is a "bug" I think, because once Query has been plot, if you deselect the "Settings -> Query" it will be visible forever.
- force vertically expansion programmatically: I would like to "force" this behavior
- graphically presence: fill the rectangle it's in my opinion non necessary if the selection is expanded and have only the lines with same ticker line where is crossing axis, so as per QueryX

[epezent]

1.) Minor ticks should not suddenly become major ticks, but gradually blend into major ticks. New minor ticks should blend in out of completely transparent ones. This will look much nicer when you do zooming, especially very rapid zooming. The point is not to have sudden changes in an image

Easier said than done, I think. I like the idea, but I won't personally be devoting time to it while other more important issues need to be addressed. By all means, give it a shot and submit a PR if you please.

2.) Add very mild animation on zooming - instead of sudden changes in zoom, zoom in gradually, starting at very fast speed, and slowing down when reaching zoom target, play the whole animation within 0.5-0.8second so it is still as sharp and responsive and not annoying. Also put it on a flag

Same. I do like this idea too. Tracy Profiler does this very nicely.

3.) When zooming in, amount of digits for each tick grows and at some point they start to overlap. I suggest skipping outputting text for ticks which will overlap with previous tick, with preference for major ticks of course

Yes, digits and overlapping axis labels are the next item on my todo list. It's not very good at the moment, and my idea was more or less the same as yours. I can work on this.

[epezent]

@ozlb, I'm not opposed to adding your single-axis Query (we would want to support X and Y) to ImPlot. What I am opposed to is baking it into BeginPlot'/'EndPlot. The input logic for drag, zoom, query, selection, and double click are already complicated enough and difficult to navigate. It's a rat's nest of if statments. Adding another thing to the mix would just make it worse.

I'd like for us to think about how we could abstract niche "plot tools" like Query and QueryX so that 1) they are separate entities/API calls and completely optional, and 2) so that users can design their own tools outside of implot.cpp. Drag/Zoom/Selection would be enabled by default, since they are common tools.

Hypothetical API (I really don't know if this makes sense, just spitballing the idea)

if (ImPlot::BeginPlot()) {
   ImPlot::ShowQueryTool();
   ImPlot::ShowQueryXTool();
   ImPlot::ShowAnnotationTool(); 
   ImPlot::PlotXXX(...);
}

I'm curious, could you make QueryX work with the current misc. API? E.g. could you design it outside of implot.cpp with these functions:

void PushPlotClipRect();
void PopPlotClipRect();
bool IsPlotHovered();
ImPlotPoint GetPlotMousePos(int y_axis = -1);
...

If not, what additional API function would you need to make it work?

[epezent]

This might mean we need to move a substantial potion of BeginPlot to EndPlot, so that tools can capture input before drag/zoom/selection are triggered and rendered. But I'm willing to do that.

[leeoniya]

feel free to steal ideas from uPlot, e.g. https://leeoniya.github.io/uPlot/demos/zoom-variations.html

high/low shaded bands are also quite useful.

nice project, btw :)

[epezent]

@leeoniya , thank you! Your project is very cool. Is there an online demo readily available?

ImPlot can do shaded regions relative to horizontal zero, if that's what you are referring to.

[epezent]

Oh, stupid question. I realize the link you sent is a demo, not a picture!

[leeoniya]

ImPlot can do shaded regions relative to horizontal zero, if that's what you are referring to.

no, like floating shaded regions:

https://leeoniya.github.io/uPlot/demos/high-low-bands.html

[epezent]

Yep, I just stumbled across that demo and realized that's what you meant. I agree, and it's low hanging fruit.

[leeoniya]

another thing that occurs frequently is missing data:

https://leeoniya.github.io/uPlot/demos/missing-data.html

uPlot also has a boolean spanGaps option per series (default is false).

[ChiefyChief23]

I'm not sure if it's implemented yet, as I've had some difficulty in trying to find a way to do it but is the ability to choose colours of a pie chart slice individually currently in? As for the use case below the colours don't match up with their meaning i.e. failure - blue, success -red, etc. So the ability to choose the colours for pie charts and I think bar charts too could be useful if not implemented?

[epezent]

I'm not sure if it's implemented yet, as I've had some difficulty in trying to find a way to do it but is the ability to choose colours of a pie chart slice individually currently in?

Yes, use:

void SetColormap(const ImVec4* colors, int num_colors);

With an array of colors ordered how you like.

[ChiefyChief23]

Coming from a scientific background I've needed in the past to have error bars both in the Y and X axis for certain scatter/line plots. I've added examples that I've seen in papers a lot below. As well this could tie in with what @leeoniya suggested with the high/low bands as in the last example. Just throwing out ideas! :D

[sergeyn]

@ChiefSeaBiscuit - I was thinking about having a separate array to specify a marker size would be useful, but you have nailed a perfect use-case for this idea.

[epezent]

@ChiefSeaBiscuit , horizontal error bars should be quite easy to implement. It's a copy/paste of the existing vertical bar functions (appending an H to the function names) and then slightly modifying the way the data is rendered. Feel free to submit a PR.

I think I might give high/low shaded plots a shot this evening!

@sergeyn , buffers for variable size marks is not a bad idea. It needs to be an optional arg or an overloaded of PlotScatter.

[ozlb]

@epezent
About new X Axis time format:

• it’s missing an API to get actual date time in double at full resolution because general time(0) has 1[s] resolution and higher resolution functions are platform specific (or am I wrong?)

• What about ImPlotTimeFmt_HrMinSMs? In my application is the one i need...
  PR ImPlotTimeFmt_HrMinSMs, NextPlotData.DragDisable #113

• About new date time picker, a “now” shortcut for max editing will be a nice plus

• For non US users, 24h time format should be take in consideration.

[ddovod]

+1 for 24h format, should be easy to implement. Probably it is enough to have a global flag/enum value somewhere in ImPlotStyle structure

[epezent]

Thanks for the suggestions. I'll look into a 24 hour option.

[epezent]

About new date time picker, a “now” shortcut for max editing will be a nice plus

@ozlb , by this do you mean "now" as in set the min/max to the current time, or "now" as in return to the current minimum/maximum of the plot if you've navigated away?

it’s missing an API to get actual date time in double at full resolution because general time(0) has 1[s] resolution and higher resolution functions are platform specific (or am I wrong?)

We can add something to implot_internal.h, but I don't think it's a good idea to expose an official "time API". That's not ImPlot's responsibility, and a lot of people will just use std::chrono anyway.

[ozlb]

@epezent
“now” to set the current date and time and to do this will be nice to have an internal function, yes

[epezent]

24 hour option

[ddovod]

Thank you so much!

[ddovod]

Let me suggest 2 more improvements:

• Option to set monday as a first calendar weekday (super minor, but anyway)
• Programmatically disable plots
  Comment regarding second point. I have 14 plots on the same canvas: the main one and 13 derivatives. I would like to initially disable all but the main plot and enable only needed derivatives using mouse. Something like SetNextPlot/ItemDisabled(true/false) or new flag would be helpful

[epezent]

@ddovod, see 04cc84e.

// Hides or shows the next plot item (i.e. as if it were toggled from the legend). Use ImGuiCond_Always if you need to change this every frame.
IMPLOT_API void HideNextItem(bool hidden = true, ImGuiCond cond = ImGuiCond_Once);

You should be able to just call ImPlot::HideNextItem() without argumetns before your derivatives to achieve what you want.

[ddovod]

@epezent Awesome! Thank you, this is exactly what I need

[PeterJohnson]

It would be nice to be able to show what plot colors are on what axes. Something like this concept:

[ozlb]

@epezent I'm using LinkNextPlotLimits() to sync and DragLineX to plot and handle queries.
Everything is OK but as you see there is a different ratio/alignment between multiple sync. charts because of the different y axis labels width.
Any idea ?

[ozlb]

@epezent I'm using LinkNextPlotLimits() to sync and DragLineX to plot and handle queries.
Everything is OK but as you see there is a different ratio/alignment between multiple sync. charts because of the different y axis labels width.
Any idea ?

Obviously it’s happening also in “real time” mode... i had some trials but probably out of direction. The only option is to do my own external axis and embed everything in a “table” context.

[epezent]

@ozlb, this is a rather complicated problem due to the order in which all of the bounding boxes are determined:

1. User provides plot frame size to BeginPlot
2. Frame padding and inner-spacing is calculated
3. Width of each y axis label region is calculated
4. Plot area width is calculated from remaining space

A few ideas):

• Allow users to specify manual widths of axes and plot area (What would the API be? It would be messy)
• Make LinkNextPlotLimits smarter so that it sets the y-axes widths based on the widest of all linked plots (This would be challenging to keep track of internally)
• Add a BeginSubplots that's better equipped to handle this type of thing

I'm swamped right now with work, but I'd be happy to continue the discussion in a new thread and review any PRs.

[ozlb]

@epezent

• Introduced BeginSubPlots and EndSubPlots

• saving pad_left and pad_right calculated max values and clamp on next cycle

#144