WPF Desktop Performance

[ibgorton]

Description

We are developing a WPF Desktop product, using the SKElement to render to screen. When drawing a SKPath with a large number of lines (1000 in our test), framerate drops significantly as CPU usage on our UI thread maxes out. Our use case could have need to display hundreds or even thousands of graphical elements.

• Is the SKElement control GPU-accelerated?

• If not, would it be worth our bother creating our own that creates a GL GRContext? To do this will require compiling our own ANGLE dll, as the nuget packages only target Windows Store, which isn't compatible with a WPF Desktop project.

Basic Information

• Version with issue: 1.60.3
• IDE: Visual Studio 2017
• Platform Target Frameworks:
  • Windows Classic: WPF Desktop 4.7.1 on Windows 10

Reproduction Link

We created a demo solution demonstrating our issue:
https://github.com/ibgorton/skia_wpf_slow

[define-private-public]

Looking at the code here:

SkiaSharp/source/SkiaSharp.Views/SkiaSharp.Views.WPF/SKElement.cs

Line 87 in b8511b7

using (var surface = SKSurface.Create(info, bitmap.BackBuffer, bitmap.BackBufferStride))

I'm pretty sure that this would be improved by fixing #552

[entdark]

You can wrap Windows Forms SKGLControl up inside a WPF Element like it is done in the skia WPF sample:
https://github.com/mono/SkiaSharp/blob/master/samples/Gallery/WPF/SkiaSharpSample/MainWindow.xaml#L29
https://github.com/mono/SkiaSharp/blob/master/samples/Gallery/WPF/SkiaSharpSample/MainWindow.xaml.cs#L151

[ibgorton]

I've spent several days poking around, building SkiaSharp, Angle, etc.

The WPF SKElement is not GPU-accelerated.

Getting ANGLE added in as a GLES context is non-trivial. I haven't succeeded yet.

For us, embedding a Winforms control is not acceptable, due to the airspace and other issues. (As an aside, it looks like Skia is built against OpenTK 1.1, which is all well and good, other than breaking changes in OpenTK between 1 and 2 and the current 3.) For now, we are going to live with the CPU-intensive software rendering, GPU offload could be nice, but we can't spend weeks or months on this one part of the application. Unfortunately, there does not seem to be any full-featured hardware-accelerated 2D option for WPF anywhere, as the problem has been asked about on various boards in various ways for about 10 years.

[entdark]

@ibgorton Up to you of course, but why SKGLControl is not acceptable?
You will be still using it as a WPF FrameworkElement anyways.
It's used so in the official samples here so it's how it is designed to be used. Works pretty good for me.

[freezy]

@ibgorton in case you're still using a CPU-based surface, I've created a proof of concept using an accelerated off-screen surface without OpenTK or ANGLE that seems to work well. More info and code here. See also #745.

[ibgorton]

Ooh, thank you! Taking a look now.

[mattleibow]

Closing this as a duplicate of #745

@freezy thanks for the work and sharing it. I'mm going to add a comment in #745 to your repo as that we can have all the information in one place.

@ibgorton did @freezy's code work for you? Please let us know in #745 !