Searching a big population for its min and max by scrolling through the whole of it, it is efficient neither with a for cycle, nor with a segmented tree. We need to investigate a parallel.for or a multithreading search.

@Padanian additional speed improvements could be made with multi-threading, but the PlotSignalConst() @StendProg proposes is remarkably faster than PlotSignal()!

I try parallel.For for a fist time it gives only 2-3 times faster rendering on my 4 core. This is not enough. Anyway can make it for a PlotSignal(). PlotSignalConst works realy fast 20-30 comparasions for each interval. Bottleneck on graphics.DrawLines() not MinMaxSearch.

Memory limitations its c# array limitations. It's trying to allocate in memory continious block for full array. Point of search is using another data types but all algoritms will be more complex and more slow.
I will try to catch mem exception and call PlotSignal, but it also has limitations just about 2 times more points

Memory limitations its c# array limitations. It's trying to allocate in memory continuous block for full array.

Consider a situation where you create a program and it runs well on your really nice computer with lots of memory. You send your program to a client who has a really bad computer and it crashes on their computer but not yours... this is what I'd like to avoid.

What if we made this simpler by not creating a new plot object? We could just add "const" as an argument to PlotSignal():

• if const is false, TreeMin and TreeMax are null
• If const is true UpdateTrees() would run and populate TreeMin and TreeMax arrays
• if UpdateTrees() crashes, TreeMin and TreeMax get set to null
• MinMaxRangeQuery() uses the tree method only if TreeMin and TreeMax are not null, otherwise it uses the old method

What do you think?

Its simple to make by call base.MinMaxRangeQuery() inside MinMaxRangeQuerry in different situation.
Upgrading for now Const to call base.Min.... before tables calculated in other thread. This replace blank screen delay with chart with slow rendering delay. Also it can be always call base.Min.. if CalcTables get and catch mem Exception.

I updated the "plot types" demo so all the signals use PlotSignalConst(). When I did this I noticed that the signal with 1k points didn't display well. This improved it, but I don't think it's a definitive solution:

https://github.com/swharden/ScottPlot/blob/58c0ea08cf5614da38742bed4cb02779680c9885/src/ScottPlot/plottables/PlottableSignalConst.cs#L18-L22

But it made me wonder - what is the lower limit (number of points) this class can display? Should this class be expected to work with an array of 10 data points?

The reason is wrong indexes in calling querry. I thinked it always call (left_index < right_index)

This looks great! Thanks @StendProg!

I added a relevant section to the cookbook:

https://github.com/swharden/ScottPlot/tree/master/cookbook#signal
https://github.com/swharden/ScottPlot/tree/master/cookbook#signalconst

PlotSignal() and PlotSignalConst() were showing the same render times initially, then I realized it was because of the multi-threading. I ended-up adding a useThreading argument (which defaults true). Let me know if you find this acceptable, or if you have a better idea for how to control this behavior.

https://github.com/swharden/ScottPlot/blob/2a3781a88a6ca2fb40f0cc617162750df4b9b6fc/src/ScottPlot/plottables/PlottableSignalConst.cs#L18-L29

Thanks for accepting. Feel free to give better name for interface method Plot.PlotSignalConst().
PlotSignalConst() always show bigger render time in single Render() call, because you should add UpdateTrees() time to you measure. It benefits on multiple Render() calls then interacting with plot, because UpdateTrees() call ones initialy.
I dont't think users really need to control this behavor. Only if someone prefer waiting full load instead of interacting with low framerates during this delay.
Options always good, but i think 99% users prefer it set to true. Anyway it need a better name in interface function to describe functionality not realization, like fastLoad, immediatelyRender, parallelLoad, notWaitFullLoad etc. You are more familar with english words....

I think the PlotSignalConst name you came up with is very good. It makes it clear that this plot type is optimized for signals with constant data.

I agree with your suggestion that the argument to turn threading on/off needs a better name (which describes its behavior rather than its implementation). This argument controls whether or not to allow the old low-speed rendering while the trees are still being calculated for the new high-speed method. It will rarely be changed, and probably only in console applications. Perhaps:

plt.PlotSignalConst(data, allowEarlyRendering: false);