Add WindowsForms PlotView based on SkiaSharp

[Jonarw]

As it has been years since I last worked with WindowsForms, if someone else feels like taking on this task, please go ahead.

Things to consider:

• Should this use GPU-accelerated rendering or not? Or both?
  • There are controls for both available on SkiaSharp side.
  • Do we need more dependencies with GPU acceleration?
• Can code be shared with OxyPlot.WindowsForms?
• Add an example browser / integrate into WindowsForms example browser?

[VisualMelon]

Given this would have to write to a buffer and copy/swap, the rendering engine could be abstracted away completely. There is no reason e.g. the ImageSharp renderer could be swapped in as well. I had a go with Skia and ran into a couple of rendering issues (apart from hating the abstraction I built), but if this would be an acceptable design I would be happy to do the leg work. My first attempt (a bit out of date) can be found here: develop...VisualMelon:WinFormsSkia

I'd envisage adding an IPlotPainter interface to WinForms which writes to a bitmap (though, this could even be mediated through OxyImage, and be platform independent), and can be passed to the PlotView as an alternative to the 'direct' renderer. There is no reason rendering can't be done off-thread to improve UX. This wouldn't be owned by the PlotView.

The advantages of such a design would be:

• Easy to add more renderers (but would you want to?)
• Minimal changes needed with respect to code reuse/sharing
• Painter interface could be used elsewhere (same abstraction could work for any UI platform, or indeed for any PNG exporter)
• Easy for user to swap out renderer:
  • Painters can be their own (tiny) NuGet package
  • Doesn't need to swap out controls in the UI (can continue to use their own extensions to PlotView)
  • If they can't use their renderer of choice for some reason (e.g. library not audited or w/e), they can use the 'native' provision as a fallback, and this can be easily configured at runtime

Obvious concerns

• Someone has to dispose the painters
• Abstractions add complexity and overheads
• Abstractions get in the way of custom performance and functionality

If we aren't sure this is bad idea yet, I'm equally happy to do the leg work so we can decide how much we hate it once it is working.

[VisualMelon]

Just a thought on the question of whether additional renderers would be a good idea: yes: at the moment, it is a miserable experience reviewing the outputs of e.g. ImageRenderContext for ImageSharp because I can't just open an example browser. Adding an ImageSharpPainter would resolve this, and make it much easier to test them. (e.g. comparing between Skia and ImageSharp is a bit of a faff at the moment: if I could switch between them with a combo-box like we can at the moment between Skia and Wpf, that would make my life much better).

[Jonarw]

Interesting thought! It would for sure be nice to be able to view ImageSharp-rendered Plots in the ExampleBrowser.

I guess it would be nice to have this IPlotPainter work with an OxyImage, so it could also be used on other platforms (i.e. WPF). The OxyPlot.SkiaSharp.Wpf PlotView in the end also just renders to an image and displays this.

We can probably not use the hardware acceleration SkiaSharp offers this way, but I don't think this is a huge concern for now. As far as I know, render time is mostly dominated by transformations etc. in the plot model itself, not the actual rendering of the shapes.

[VisualMelon]

It looks like OxyImage isn't meant to be just a block of color, but it hasn't been touched since 2014. Would it make sense to abandon it's dreams of becoming a compact image representation with support for multiple encodings, and instead make it just a block of color so we can add a foundation level IPainter with method void Paint(IPlotModel model, OxyImage image); to live alongside IExporter? No reason we can't have a different interface, but since it's there...

[Jonarw]

I haven't really done much with OxyImage to be honest. Is the functionality with the different encodings actually used anywhere?

Alternatively we could keep this as is and create a new OxyBitmap struct/class which is just a 'block of color'.

[VisualMelon]

@Jonarw yeah, thinking about it that would be a much better idea, and would mean I can get on with implementing everything rather than trying to make decisions I can't make. OxyBitmap it shall be.

[upics]

@VisualMelon @Jonarw it would be interesting to have an implementaion of this kind, mainly with graphic accelleration with opentk. Do you still take in consideration this develop ? Thank you

[upics]

UPDATE: I have implemented the skiasharp with GL on oxyplot libraries, but i noticed that in a performance comparison,rendering is slower than simple system.drawing or skiasharp implemented by you @VisualMelon.

I'm still investigating to understand why.. i'm keeping updated this thread.