Replacement of GL methods with Silk.NET

[HurricanKai]

What does the pull request do?

This replaces Avalonias own GL bindings with Silk.NET, @Perksey mentioned to me that this was not a thing, and I gave it a shot this weekend.
I believe this is much easier to maintain, and Silk.NET always tries to improve bindings in terms of performance and usability, these improvements will trickle down to Avalonia with little effort now (updating a NuGet package).
This also "solves" #4310 as an added bonus (giving OpenGLControl much more power)

What is the current behavior?

Avalonia has it's own GL bindings, which are more difficult to use and have a higher startup cost.

What is the updated/expected behavior with this PR?

There should be no visual changes anywhere.

How was the solution implemented (if it's not obvious)?

I believe this is obvious looking at the changes in src/Avalonia.OpenGL/ from where the changes simply trickled down, but I can detail this if needed.

Checklist

• Added unit tests (if possible)? (I believe this should be covered by existing unit tests)
• Added XML documentation to any related classes?
• Consider submitting a PR to https://github.com/AvaloniaUI/Avaloniaui.net with user documentation

Breaking changes

Breakes users of OpenGlControlBase

class OpenGlControlBase
{
-    protected virtual void OnOpenGlInit(GlInterface gl, int fb)
+    protected virtual void OnOpenGlInit(GL gl, uint fb)
-    protected virtual void OnOpenGlDeinit(GlInterface gl, int fb)
+    protected virtual void OnOpenGlDeinit(GL gl, uint FB)
-    protected virtual void OnOpenGlRender(GlInterface gl, int fb)
+    protected virtual void OnOpenGlRender(GL gl, uint fb)
}

Changes to be done / considerations

• GlInterface currently still exists as
  • it contains GlContextInfo which is used (?) for other loading mechanisms, ie egl...
  • it contains CompileShaderAndGetError but I believe this could be moved elsewhere
• verify performance assumptions. (WIP right now)

[kekekeks]

1. avalonia own bindings are designed to

• work with both OpenGL and OpenGLES, potentially on broken/incomplete implementations
• do not depend on external libraries
• be OpenGL-binding-agnostic (so different binding libraries could be used)

2. the idea was to provide a minimal required API from Avalonia itself and provide integrations with Silk.NET, OpenTK and others as separate nuget packages (SilkNetControl, OpenTKControl, etc, probably with more fine-grained control over reusing one OpenGL context for multiple controls).

I'd be happy to move OpenGlPage example to Silk.NET (and remove APIs needed only for that example page from Avalonia.OpenGL), but the rest of the core library has to stay as is.

[kekekeks]

Also, note that Silk.NET is not strong-named, so we can't have it as a dependency for core and platform assemblies.

[HurricanKai]

I understand the problem of not wanting an(other) external dependency, but I'm confident Silk.NET works well with both partial, OpenGL, and OpenGLES implementations (though I will look into changing the reference to the OpenGLES package then), and I also believe Silk.NET is easy to integrate with other bindings due to us exposing all the loading mechanisms.
Not exactly an OpenGL expert, but I believe if Avalonia exposes it's OpenGL context that means no complicated sharing mechanisms have to be implemented?

Also, note that Silk.NET is not strong-named, so we can't have it as a dependency for core and platform assemblies.

this should be solved soon, once the transition to the dotnet foundation has completed.

If a dependency is a big problem though, do close this PR, as I don't think this can lead anywhere in that case.

[kekekeks]

works well with both partial, OpenGL, and OpenGLES implementations (though I will look into changing the reference to the OpenGLES package then)

OpenGL and OpenGLES are different APIs. They have a shared subset that we are using to wire up ANGLE, but that's it. There is no binding library I'm aware of that exposes only the shared subset.

I believe if Avalonia exposes it's OpenGL context that means no complicated sharing mechanisms have to be implemented?

The "primary" OpenGL context should not be used by the user code except for rare circumstances. One is expected to create their own context (OpenGLControlBase does that under the hood).

[grokys]

I agree that we don't want a dependency on a 3rd party library at this level. That would mean that if someone wants to use Silk.NET on top of Avalonia they'd be forced to use a version compatible with the version that Avalonia uses. We've had these sorts of dependencies in Avalonia before in the past and it always causes problems for somebody.

[HurricanKai]

Fair point. We will introduce (a) package(s) to support using Silk.NET on top of Avalonia instead.

[s5bug]

Where can I find this? I have a Core DLL, separate from my main App, that I don't want to depend on a specific GUI framework; I want things in Core to just take a generic GL Context, and then App can pass a GL Context from Avalonia to it.

"silknet avalonia" gives no Google results, where can I find a well-maintained SilkNetControl?

[Perksey]

It hasn't been developed yet. It's on our list for Silk.NET 3.0.

[s5bug]

Sounds good. Is there something I should be doing in the mean time wrt not tying GL-dependent code to Avalonia?