[FEATURE] Support Direct3D

[Kation]

Is your feature request related to a problem?

1. Some GPU or its driver doesn't support Vulkan.
   For example, Intel Xe Graphics currently driver will return null ptr when get procedure address for some name.
   Then GRContext.CreateVulkan will return null.
2. Some environment only support OpenGL 1.1.
   For example, Virtual Machine without GPU. Or remote control without RDP with Intel Xe Graphics.
   Then GRContext.CreateGl will return null.

Without Vulkan and OpenGL, we can only use CPU to render images.

Describe the solution you would like

Add D3D support with Windows os.

Describe alternatives you have considered

Add define SK_Direct3D when compile native skia so that I can use it with pinvoke and reflection.

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[Kation]

I have tried to use SharpDX to create backend. But I found there is no api define in libSkiaSharp because compile without define SK_Direct3D.

[996666925]

👍👍👍

[Shunfeng88]

The code demonstrates a deep understanding of the domain, incorporating relevant design patterns and domain-specific optimizations that reflect your expertise and intimate familiarity with the subject matter

[Kation]

@mgood7123

Skia have define D3D functions:
https://github.com/mono/skia/blob/a0008792c861228872a0a21f5f3422c4c8824720/include/gpu/GrDirectContext.h#L105-L112

But our SkiaSharp does not add those define:
https://github.com/mono/skia/blob/a0008792c861228872a0a21f5f3422c4c8824720/include/c/gr_context.h#L28-L33

[gmurray81]

Just as a warning here. Over the years I've run into various areas where Direct2D performs in degraded ways compared to Skia software or Skia OpenGL/Vulkan backends. Mostly this has to do with conversion of Path geometry into tessellated meshes. If you have paths with high frequency changes in direction, this seems to be a terrible performance case for Direct2D.

Now, maybe the Direct3D backend for skia sidesteps this stuff if it is using lower level primitives and skipping all the Direct2D stuff. But I'd keep an eye out for degraded path rendering scenarios if the backend touches any of the high level stuff.

[ShadowMarker789]

With mono/skia#121 Complete, there is some potentiality of this moving forward, and I am very excited about this.

[mattleibow]

Yes, I am busy reviewing and making sure it is all green. You can help by treating the nuget artifacts on the SkiaSharp PR https://dev.azure.com/xamarin/public/_build/results?buildId=137303&view=results

[ShadowMarker789]

Yes, I am busy reviewing and making sure it is all green. You can help by treating the nuget artifacts on the SkiaSharp PR https://dev.azure.com/xamarin/public/_build/results?buildId=137303&view=results

Am I missing something? I see zero (0) artefacts there.

Is there a particular preview version you mean instead?

[jeremy-visionaid]

@ShadowMarker789 Not just you - the artifacts are gone. I can see nugets artifacts for a later build though:
https://dev.azure.com/xamarin/public/_build/results?buildId=137454&view=artifacts&pathAsName=false&type=publishedArtifacts

[mattleibow]

MERGED 4fb125b

In about 3 hours a new build will appear in the preview feed for everyone to enjoy. Thanks OpenGL, you had your time, Direct X here we come.

For things like views and other D3D libraries (like Silk.NET), please open new issues and also new PRs ;)

[gmurray81]

@mattleibow Is any of the native D3D path rendering used in the D3D ganesh stuff? Or is it only lower level stuff/shaders that get used? I'm a bit concerned because in my experience the D3D path tessellation stuff is pretty awful compared to Skia...

[mattleibow]

@gmurray81 I am not sure. I suppose we could write a semi-complex image and benchmark on the backends to see which is faster. But, I assume that Google would have made the backend as fast as possible. We have been using Direct3D already with WinUI and UWP via the ANGLE wrappers/proxies. So I can't imagine that it is that much slower.

Also, @jeremy-visionaid said: #2823 (comment)

OK, I've got a working proof of concept using the D3D backend. Took me a little while to check the performance. Looks about 5-10% faster than the ANGLE build for our app...

If you have a scene that you think is going to hit some slow paths, we could set up a test app to render it and check.

[gmurray81]

@mattleibow
I'll try to put something together if I have time. The basic way to simulate the issue, though, is to draw a path from left to right and emit a segment roughly per pixel, but use entirely random y coordinates for each. To see the impact this causes, repaint with new y coordinates as quick as possible and observe the framerate. This creates a line that chaotically oscillates in y coordinate. In WPF and the versions of Direct2D that I've tried, this usually makes the path rendering pipeline fail hard. I assume its a really bad edge case in the meshification of the path.

Skia briefly had this issue also. When they initially turned on hardware acceleration in chrome back in the day, they had a similar perf issue with these shapes, that they subsequently fixed. I'm not positive how they fixed it. Perhaps they detect this scenario and bail out and do a CPU based rasterization instead. Or maybe they fixed something in the algorithms.

Now, this is not really a useful shape, to have a really chaotic path, but it still winds up coming up for me. I make charting components, and for whatever reason the thing any customer tries first is to just assign completely random data. The problem is, though that this winds up creating bottlenecks in the render pipeline outside of my reach. Which is pretty frustrating.

Here's the link to the bug that I reported to chrome back in the day. It has a simple JS repro against the Canvas API in the browser, and it represent something that would make WPF/Direct2D cough up blood, unless maybe its fixed in the latest Direct2D versions? I think I even tried the scenario in that new 2D windows api... cant' recall the name ATM, and it was still an issue there...

https://issues.chromium.org/issues/40106266

BTW, I feel like I've seen this slow down in Chrome lately, and reported a new bug. But I think they've had issues reproducing a perf drop, and I haven't had to opportunity to provide them more info. But it's also possible that I'm hallucinating, or that I just have a much higher DPI monitor than the last time I tried some of this stuff:

https://issues.chromium.org/issues/382503551

[gmurray81]

sorry, one of the links was wrong, edited

[gmurray81]

note that paths with the same number or segments but less chaos perform much better in all 2D apis, so something about the chaos breaks the assumptions that the algorithms in the tessellation/meshification are making. I would say it has something to do with the points having big mitered joins or complex rounded triangle fans, but from what I recall, I don't think the type of line join had much effect on the performance, at least in WPF/Direct2D, so maybe it may have something to do with a geometry simplification step before the other steps...