IRenderer now describes a rendering system, and IPlottable and IRenderable objects do not depend on System.Drawing at all anymore. Every drawing action is performed by calling a method of IRenderer.

By default a SystemDrawingRenderer is created and used, but there is a clear path forward to create controls which use custom renderers (e.g., SkiaSharpRenderer).

@StendProg you may be interested to see there is now a working SkiaSharp control.

This project still needs a lot of improvement, but this early proof-of-concept is very encouraging!

Hi Scott (@swharden ),

@StendProg you may be interested to see there is now a working SkiaSharp control.
This project still needs a lot of improvement, but this early proof-of-concept is very encouraging!

This works awesome! After some tunings (disable rounded corners, call signle Canvas.DrawPoints()) i get two 20_000 points Scatters work at acceptable 20-30 FPS.

I pereodically check your work on this branch. Of course, minor nitpicks arise, but I do not consider them significant enough to distract you from your main work. And now I will not.

The only thing that raises concerns is that you have started too large-scale changes. Wouldn't have stopped in the middle.

You can leave the implementation of the Skia Renderer for later. Maybe I can help when the architecture is finally settled.
The only thing to keep in mind is to avoid a lot of simple calls to the IRenderer, and instead try to make a single call with multiple data like Renderer.DrawPoints().

I fully agree that such changes deserve an major version increment. Good work!

Thank you for your feedback @StendProg!

I too am concerned about the scale of these changes and the breaking API, and it sounds like we are in agreement that a major version increment is the way to go here. Maintaining ScottPlot4 while developing ScottPlot5 in a separate folder seems like a good way to move forward, since I won't have to stop work on either one to support the other.

I learned a lot by working in this branch, especially about how to support multiple axes and improve the layout system. I think I can take much of what I have learned here and apply it to ScottPlot 4.0 in a way that is non-breaking. I'll probably stop work on this branch for a few days to work on ScottPlot 4, then return to this with fresh eyes.

Thank you again for your input along the way!

This is a great start, but there are many concepts here which can be applied to ScottPlot 4 to make it better (without throwing it away and starting over).

I'm going to close this PR and copy these files into a folder in the main repository so it can be used for experimentation.

Hi Scott,

When will be the next stable (Scottplot 5) release. Does it supports more than 2 y-axis (additional/multiple y-axis for multiple plots) ?
We are in process of migrating ZED graph to Scottplot. Hence required multiple y-axis support.

HI @NarasimhaKulkarni,

After a lot of work I was able to implement all these features while retaining the original ScottPlot 4 API (although some methods were marked obsolete). Because of this, plans outlined above eventually became ScottPlot 4.1, which is currently on NuGet as a pre-release package.

ScottPlot 4.1 indeed supports multiple axes and can be used now

• https://swharden.com/scottplot/faq/multi-axis/
• https://swharden.com/scottplot/cookbooks/4.1.9-beta/#multi-axis

Good luck with your migration!