Add WindowsForms PlotView based on SkiaSharp · Issue #1516 · oxyplot/oxyplot · GitHub
Skip to content

Add WindowsForms PlotView based on SkiaSharp #1516

Open

Description

@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?

Activity

  1. VisualMelon commented on May 12, 2020

    @VisualMelon
    Contributor

    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.

  2. VisualMelon commented on May 14, 2020

    @VisualMelon
    Contributor

    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).

  3. Jonarw commented on May 14, 2020

    @Jonarw
    MemberAuthor

    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.

  4. VisualMelon commented on May 14, 2020

    @VisualMelon
    Contributor

    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...

  5. Jonarw commented on May 15, 2020

    @Jonarw
    MemberAuthor

    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'.

  6. VisualMelon commented on May 15, 2020

    @VisualMelon
    Contributor

    @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.

  7. upics commented on Mar 25, 2022

    @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

  8. upics commented on Apr 7, 2022

    @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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions