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.