Opengl full

[devel0]

What does the pull request do?

Full GL api as from https://github.com/KhronosGroup/OpenGL-Registry/blob/master/xml/gl.xml with documentation from https://github.com/KhronosGroup/OpenGL-Refpages/tree/master/gl4.

What is the current behavior?

in GlInterface currently there are only some of gl api available without intellisense documentation neither for parameters due to the property get instead of method declaration.

What is the updated/expected behavior with this PR?

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

Autogenerated using tool from https://github.com/devel0/netcore-sci/tree/d23959d0fba177382cd23241a6cc51a3ca3356c3/tools/gl-csharp-bindings-generator.

Checklist

• Added unit tests (if possible)?
• [X ] Added XML documentation to any related classes?
• Consider submitting a PR to https://github.com/AvaloniaUI/Avaloniaui.net with user documentation

Breaking changes

• following gl.xml spec some int var should declared as uint
• most methods have enum group

var oneArr = new int[1];
gl.GenFramebuffers(1, oneArr);
_fb = oneArr[0];
gl.BindFramebuffer(GL_FRAMEBUFFER, _fb);

becomes

var oneArr = new uint[1];
gl.GenFramebuffers(1, oneArr);
_fb = oneArr[0];                    
gl.BindFramebuffer(FramebufferTarget.GL_FRAMEBUFFER, _fb);

Fixed issues

none

[dnfadmin]

All CLA requirements met.

[devel0]

Another possible better solution would to use OpenGL.Net but I found the way proposed in this PR more immediate in terms of integration with current code and I haven't all the knowledge required to consider that integration; this PR effectively only extends available api methods, document and type enum for them.
Eventually if useful I can consider to add Attributes to methods describing extension that can retrieved from gl.xml spec file.

[Gillibald]

You are changing int to uint all over the place. I don't think that is really needed and just makes it harder to review this.

[kekekeks]

I'm sorry, but we can't accept that to be included in the framework itself.

We have to support rendering through both OpenGL ES and desktop GL, so the idea is to have a minimum set of APIs that are present everywhere and absolutely required to get things going.

Our built-in OpenGL bindings are not intended to be used outside of the framework. The only APIs that should be used by end-user apps are context management (creation, MakeCurrent) and glGetProcAddress.

The rest should be done via some exiting OpenGL bindings such as Silk.NET OpenGL.Net and OpenTK. They do support working on top of pre-existing OpenGL context with custom glGetProcAddress delegate.

The general plan was to provide integration shims for those bindings, so there would be OpenTKControl, SilkNETControl, OpenGLNetControl working on top of OpenGLControlBase and shipped via separate NuGet packages.

[kekekeks]

e. g. this change just breaks the code on OSX. OSX lacks compatibility context support for 3.0+ profile, so functions that are core in 3.0 can't be called via OES-suffixed versions.

[kekekeks]

No, it's not, in fact, packable on Linux

[devel0]

@kekekeks Thanks for clarification, I totally agree with you.

I would be useful to specify in the roadmap what you said here about OpenTKControl, SilkNETControl, OpenGLNetControl just to allow anyone to know directions.

Consider that I wrote extension proposed in PR just for my need because I'm new to 3d and I got some trouble without having intellisense for example for a function like glPolygonMode etc, but when I did these for my need I thought that opening a PR could helpful to clarify the question about the infrastructure you described which I eager to see in operation.

Thanks for the work you are forwarding about 3d control availability for the AvaloniaUI.

[devel0]

I wrote a PR #4310 that should fit with needs and its very essential,
Hopefully could fit with your requirements to avoid incompatibilities.