Looking to support OpenGL.Net in Qml.Net, looking for guidance.

[pauldotknopf]

See this issue.

Using this lib would be perfect. However, I'm a little hestitant to use it.

It looks as if OpenGL.Net loads it's own libs. Qml.Net has some complicated runtime discovery. When it finds a runtime, the libs themselves are already linked correctly to OpenGL.

Looking in GetProcAddressGL.cs, it seems as if you could potentially make this interfaces public so that Qml.Net could provide it's own implementation of GetProcAddress. Ideally, I'd like this to call Qml.Net's native shim (libQmlNet.so, libQmlNet.dylib, etc), which would have OpenGL linked properly to it. Doing it this way would ensure we are using the OpenGL version that Qt is compiled against.

What do you think?

[pauldotknopf]

I'd like to use QOpenGLContext::getProcAddress to load the function pointers.

[luca-piccioni]

My understanding is that Qml.Net is taking the responsability of creating a window, and Qml.Net users are able to code OpenGL in C++ or C# seamlesslly, isn't? Indeed the users are free to choose any OpenGL wrapper are used to. Do you C++? Use GLAD, or Qt, for example. If you C#, then you can use OpenGL.Net for calling OpenGL functions. I think that the misunderstanding is that Qt is not compiled against any OpenGL library (since it's implemented in driver), or precisely, it links the standard OS libraries available on the various platforms that everybody can use. Or using QT requires the use of its own wrapper?

Maybe, do you intend to wrap C++ functions like here? I don't think this make sense.

[luca-piccioni]

@pauldotknopf You linked QT Open module, but it clearly states:

Warning: This module should not be used anymore for new code. Please use the corresponding OpenGL classes in Qt GUI.

Going further in the mentioned Qt GUI, the Qt wrappers seems based on QOpenGLExtraFunctions, which contains an essential subset of the entire OpenGL API.

The user @define-private-public maybe is requesting a QOpenGLShaderProgram wrapper, instead of full raw OpenGL wrapper. Otherwise he should not ask for OpenGL support in Qml.Net. @TheRamsWay suggest to integrate OpenGL.Net in Qml.Net, but sincerely I do not understand what parts of Qt should be implemented.

The fact is that basic OS library for OpenGL is used for wglGetProcAddress (or eglGetProcAddress) (or anything else as described here). These functions are used by Qt and by any OpenGL library loader/wrapper around the world. Indeed there's no "correct OpenGL implementation" in Qt that you should link to.

Maybe exotic setup (i.e. OpenGL implemented by ANGLE) could be error prone, but in the end it means loading function pointers from the correct library having standard names.

[pauldotknopf]

My understanding is that Qml.Net is taking the responsability of creating a window, and Qml.Net users are able to code OpenGL in C++ or C# seamlesslly, isn't

Yup.

I think that the misunderstanding is that Qt is not compiled against any OpenGL library (since it's implemented in driver)

Hmm. When you use CONFIG+=gui in your app, it links your app/lib against:

libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007fd9a3bed000)
libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x00007fd9a34af000)
libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007fd9a33f2000)

I think that the misunderstanding is that Qt is not compiled against any OpenGL library (since it's implemented in driver), or precisely, it links the standard OS libraries available on the various platforms that everybody can use. Or using QT requires the use of its own wrapper?

Qt requires it's platform integrations (windows/xcb/osx) to provide the function pointers (see this). I think it's a good idea to ensure that any approach that I take for exposing OpenGL in C#, that it sits on top of these platform plugins in Qt. That way, for example, if someone is using "offscreen" or "directfb" at runtime, the features of OpenGL will match what their running platform supports.

Otherwise he should not ask for OpenGL support in Qml.Net. @TheRamsWay suggest to integrate OpenGL.Net in Qml.Net, but sincerely I do not understand what parts of Qt should be implemented.

I guess I'm not seeing the disconnect on my end either. Sorry.

[TheRamsWay]

My understanding of this was that Qt connect() function would allow you to run code (your rendering code with OpenGL.Net ) before Qt has rendered its UI in the window. Basically, Qt is providing a GL context to display your OpenGL things and Qt becomes an overlay.

[pauldotknopf]

@TheRamsWay, you are correct. Qml.Net would provide the proper spot to perform OpenGL commands (doing connect() for you), but I think that is beyond the scope of this issue.

The issue really is how do we load the function pointers.

[luca-piccioni]

The commit above should give you access for setting a custom function loader for each API implemented. This commit does not alter the fundamental behavior of the build-in function loaders.