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.

As promised in #219, I managed to implement GPU-accelerated heatmaps! I haven't done any serious benchmarks but the performance gains I've seen in some applications are quite significant.

This PR is pretty much ready to be merged, but there are some small issues that should be addressed:

1. OpenGL doesn't support double nor *int64_t (aka ImU64/ImS64). If this kind of data is passed to a heatmap, it is internally converted to float or ImU32/ImS32 (respectively).
2. When using OpenGL acceleration, the interpolation tables for heatmaps are unnecessary. Maybe we could only enable them in case this optimization is disabled
3. Right now I use the same trick ImGui's main.cpp file uses to access OpenGL functions, which is rely on a macro definition to include one of the many supported libraries. It is possible to implement our own OpenGL loader so that we don't rely on any external library (ImGui will still depend on that library though), but that would add a bit of complexity maybe.
4. Log-Log, Lin-Log and Log-Lin axis are not yet implemented.

I tried to implement this as straightforward as possible, and with as little modifications to the 'core' of the library as possible. Also, all the implementation details are inside the file backends/implot_opengl.cpp. If the macro IMPLOT_ENABLE_OPENGL3_ACCELERATION is defined, then that file will compile and the library will use the shader-accelerated code. If not, it will default to the current method.

I will update this PR once I have some benchmarks to show you, but the performance gains should be significant :)

Any comments, optimizations, questions or changes are always welcome :D

Moving discussions of multi-axis support to a separate issue. Previous comments below:

https://github.com/epezent/implot/issues/1#issuecomment-626177655

I wish I could use ImPlot for audio data, which e.g. Spotify delivers as Int16 (signed) interleaved samples, which feed to the audio device as same. My FFTs yield integer ranges as well. I'd rather avoid converting entire blocks of ints to floats for trivial display, simply to skirt a library inflexibility.

ImPlot's core piece - the data it operates on and that data's type - being limited to floating point is a fundamental inconvenience. @ocornut's suggestion to templatize the datatype internally, then expose type-specific APIs, seemed to be summarily dismissed. https://github.com/epezent/implot/issues/36#issuecomment-630772991

@epezent you mentioned there that templates "make the header a mess" but the dual "float then double" repeated function prototypes don't seem elegant either. Does anyone else have need for different dataset types? Surely someone has. I'm considering a fork to investigate a templated approach but would rather not repeat someone else's failed attempt at wheel reinvention. :-)

By the way, @epezent, nice work on this! It looks great.

Announcements of changes and new features will be posted here. Click Subscribe to the right to receive updates!

PLEASE DO NOT COMMENT ... EMOJIS ARE WELCOME :)

To have same Y axis padding, ImPlot::BeginSubPlots() must be called before 1st ImPlot::BeginPlot() and ImPlot::EndSubPlots() must be called after last ImPlot::EndPlot().

https://github.com/epezent/implot/issues/53#issuecomment-723526658

Hi. Thank you very much for such an amazing library! Would you mind to implement a candlestick chart? It would be great to have a function with signature like

void PlotCandlestickChart(const char* label_id, const float* xs, const float* opens, const float* closes, const float* lows, const float* highs, int count, int offset, int stride)

I have a very basic implementation which looks like this The implementation is very straightforward and based on the error bars code, but I can share it here if you want.

Let me explain some problems I've faced here:

1. As you can see, I use 2 colors for candles. The main problem is you cannot show a 2-colored marker in the legend box. I see 2 solutions here: either to support a multicolor markers in the legend, or use one color, but mark rising and falling candles with solid and hollow filling. I'm not sure what option is more suitable for implot.
2. It would be great to be able to show a time on the X axis in some form.
3. I'm not sure if this is a topic for implot, but it would be great to have some tools to show the candle parameters (OHLC values) when mouse is hovered or clicked the candle.

Please let me know if I can help somehow. Thanks!

Your library is truly awesome, congrats!

When it come to C++ libraries, most of the time there is most of the time no easy way to get a working demonstration. First, you have to download the code setup the build environment, etc. There, C++ is lagging behind some other languages, especially on the web.

However, emscripten can help a lot in this case. In order to tryr to fill this gap, I spent a few hours this afternoon in order to make an online demo of your library.

It is live here, and the source code for this demo is on github.

Here are some screenshots:

implot demo:

source code browser with access to the different demos:

It runs at 120 fps, except for the benchmark (which I suspect is blocked because it may consume too much memory)

If you are interested, you could may be use this in order to add an interactive demo in your Readme. Feel free to deploy the wasm files on any server of your choice.

Thanks

When you have super dense plots (many points hit a pixel), you can see holes in the rasterization pattern. Consider following plot, which plots a line: ImPlot::PlotLine("line, [](void*, int idx) { float v = float( 3.0 * idx / (1000000 - 1)); return ImVec2(v, v); }, nullptr, 1000000); You can observe single pixels missing on a plot. I believe it's because triangles generated for line segments do not have exactly same coordinates. (PS. you need my million line PR for this to work)

Hello! I'm a bit confused with the box selection process. Firstly, there is a line that ImPlotFlags_Selection flag was changed to ImPlotFlags_BoxSelect (see implot.cpp), but I can't find neither statement that ImPlotFlags_BoxSelect has been deleted, nor that it's being used in the code. So the main question is how to enable box selection/zooming?

The problem

Just indexing the data (patched out ImPosMod() with just idx) gives a 30% fps boost in the benchmark (mahi-gui) compared to the current implementation honouring offset, stride. Before ImPosMod() was patched into it, the custom getter function version was faster. To my testing the penalty of using a getter function versus raw array pointers (all without ImPosMod and OffsetAndStride()) is surprisingly low (I suspect because there is already a lot of function calls for drawing each data point anyways).

~~The~~ A Solution

One way to improve this is to add overloads without offset and stride parameters (and special getters in implot_items.cpp) for all functions. This will lead to double the amount of template instantiations though. A leaner variant would be to add overloads just for the _G functions. This also gives about 30% more fps in the plots benchmark.

If you have a better idea how to solve this I'm happy to rebase the PR.

Please add to the library a "scatter" plot on polar axis. It will be good to have to choose a "scatter" view:

1. Arc figures. Inspired by nttiny library and looks like this

2. Circle scatters. It looks like matplotlib scatter plot

That's my contribution to your project, bindings for .NET which, among other things, includes implot documentation directly from within IntelliSense.

Thank you, have a good year!

I'm trying to plot data with hundreds of thousands of data points.

It would be ideal to have implot incorporate an LTTB solution to automatically downsample data as the user zooms out / in of the data

The diff 63d5ed94b77acdf73201a00074bfd80467f50f0a introduced some breaking changes in how ImPlot::PlotLine() works.

Before:

After:

Code:

auto Sparkline = [](const char* id, const float* values, int count, float min_v, float max_v, int offset, const ImVec4& col,
                    const ImVec2& size) {
	ImPlot::PushStyleVar(ImPlotStyleVar_PlotPadding, ImVec2(0, 0));
	ImPlot::SetNextAxesLimits(0, count - 1, min_v, max_v, ImGuiCond_Always);
	if (ImPlot::BeginPlot(id, size, ImPlotFlags_CanvasOnly | ImPlotFlags_NoChild)) {
		ImPlot::SetupAxes(nullptr, nullptr, ImPlotAxisFlags_NoDecorations, ImPlotAxisFlags_NoDecorations);
		ImPlot::PushStyleColor(ImPlotCol_Line, col);
		ImPlot::PlotLine(id, values, count, 1, 0, offset);
		ImPlot::PushStyleVar(ImPlotStyleVar_FillAlpha, 0.25f);
		ImPlot::PlotShaded(id, values, count, 0, 1, 0, offset);
		ImPlot::PopStyleVar();
		ImPlot::PopStyleColor();
		ImPlot::EndPlot();
	}
	ImPlot::PopStyleVar();
};

Hi!

Thanks for this great library. I have a question: How do I persist the location and inside/outside flag of the legend so that if the app is closed and opened again the legend is still at the same position. Is there a method to query the state of the legend? Or something like SetupLegend(ImPlotLocation *location, ImPlotLegendFlags *flags) with references which modifies the current location and flags when the user configures the legend. Then location and flags could be saved on exit and loaded on start of the app.

In implot.h, you have:

// Double precision version of ImVec2 used by ImPlot. Extensible by end users.
struct ImPlotPoint {
    double x, y;
    ....
    double  operator[] (size_t idx) const { return (&x)[idx]; }
    double& operator[] (size_t idx)       { return (&x)[idx]; }
    ....
};

These functions do not do bounds checking and may thus read outside the struct's values. ImGui's ImVec2 does the following:

struct ImVec2
{
    float                                   x, y;
    ....
    float  operator[] (size_t idx) const    { IM_ASSERT(idx <= 1); return (&x)[idx]; }    // We very rarely use this [] operator, the assert overhead is fine.
    float& operator[] (size_t idx)          { IM_ASSERT(idx <= 1); return (&x)[idx]; }    // We very rarely use this [] operator, the assert overhead is fine.
    ....
};

And additionally has a pair of macros IM_MSVC_RUNTIME_CHECKS_OFF and IM_MSVC_RUNTIME_CHECKS_RESTORE that it wraps the struct with. Since implot.h imports imgui.h, you could directly use IM_ASSERT as well as the above other macros. Could you consider doing so?