X11::GLX as possible OpenGL::GLX support

[devel-chm]

@nrdvana has recently released his X11::GLX module providing the GLX to OpenGL glue needed for X11 programming. He has also released X11::Xlib this spring for more general X11 programming. I was able to build X11:Xlib on cygwin/win7 but there were test failures for X11::GLX. If those problems can be resolved, this module could be the basis for the desired OpenGL::GLX functionality from OpenGL to make it (and more!) available for OpenGL::Modern users.

https://github.com/nrdvana/perl-X11-GLX
https://metacpan.org/pod/X11::GLX

[nrdvana]

I'd be happy to assist adding any API you need in the X11::GLX module.

But also, in my recent experience working with Xlib, I've learned that it's really a mess, and that building on xcb (the new C bindings for X11) would be preferred. However, all the glX functions require a "Display*" and this is specific to Xlib. xcb uses "xcb_connection*" for its connections. If anyone knows a way to make GLX functions operate directly on xcb, I'd be interested to know.

[mohawk2]

Does GLX really bring any capability that is worth making an effort to create a binding for?

[nrdvana]

GLX is the only way to do a few fancy things, like transparent windows that don't intercept mouse input, or server-side rendering where multiple applications can share the GL resource IDs.

If you know your app will only ever run on X11, it's also the lightest weight option for setting up OpenGL, such as for the DeLorean dashboard.

The binding is already written, but I'm not sure what @devel-chm had in mind for tying it into OpenGL::Modern.

In the long run, I'll probably need to rewrite my stuff for Wayland anyway.

[mohawk2]

My feeling therefore is that it might be useful to detect and offer bindings for GLX within this thing if found, but not at the cost of lots of effort? EDIT - does that make sense to you?

[nrdvana]

My thought would be that anyone who wants to use X11 + GLX directly probably ought to install the modules directly. In order for OpenGL::Modern to export the GLX symbols on its own, you'd either be exposing all the X11 integer IDs with no way for the user to manipulate them, or need to copy a large amount of auxillary code from X11::Xlib and X11::GLX, or have OpenGL::Modern load X11::Xlib and X11::GLX and then re-export symbols that came from those modules. I'm not sure how much convenience the third case would provide.

Now, if there is something in OpenGL::Modern (or which @devel-chm was planning to add to OpenGL::Modern) where you just want to set up the easiest GL context with whatever is available, then I think it makes a lot of sense to test for whether X11::GLX is installed and use it as one of the options. I do this in OpenGL::Sandbox make_context

[mohawk2]

@nrdvana Could I ask you to look at the new OpenGL::GLX (in the new CPAN OpenGL distro) and see what you think? I carved out just the GLX (and glp*) stuff into that, as an independently-loadable module. I am hoping that might solve this problem.

[nrdvana]

Currently, OpenGL::GLX has an extremely minimal list of functions:

our @func = qw(
   glXSwapBuffers
   XPending
   glpXNextEvent
   glpXQueryPointer
);

X11::GLX has:

glXQueryVersion
glXQueryExtensionsString
glXChooseVisual
glXChooseFBConfig
glXGetFBConfigs
glXGetFBConfigAttrib
glXGetVisualFromFBConfig
glXCreateContext
glXCreateNewContext
glXMakeCurrent
glXSwapBuffers
glXDestroyContext
glXCreateGLXPixmap
glXDestroyGLXPixmap
glXGetContextIDEXT
glXImportContextEXT
glXFreeContextEXT
glXQueryContextInfoEXT

This larger list of functions can't be easily added to the OpenGL or OpenGL::Modern dists because the arguments include:

Display*
Screen*
XVisualInfo*
GLXFBConfig*

each of which is a C pointer type that needs to interoperate with Xlib in order to be useful. This is what I ran into when I went down this rabbit hole in 2014, and Implemented it all in C directly. When I decided to bring more of it perl-side in 2017, I decided the first step was to enhance X11::Xlib so that it actually had these as nice objects, and then I wrote X11::GLX building mostly on top of X11::Xlib, because the public API of GLX doesn't really need much from OpenGL at all. Most of OpenGL just assumes "a context exists" and the only glx function that any GL program can really use without messing with X11 details is glXSwapBuffers.

In fact, of the four functions implemented by OpenGL::GLX, glXSwapBuffers is the only one that is actually a GLX function. The other 3 are weak attempts at messing with X11 details without fleshing out the full X11 API. I would expect that any program using those 3 would be improved by using the equivalent methods from X11::Xlib.

[mohawk2]

My thinking now is that OpenGL::Modern only does, and only should do, actual OpenGL stuff. Opening the window, as done by GLFW, or GLUT, or GLX, should not be in this module, so therefore I think this issue is actually somewhat moot.

@nrdvana What do you think?

[nrdvana]

Yeah I agree. I'm not sure whether just removing glXSwapBuffers would break someone's code though. I'm not sure how many users there would be when the X11 support was so minimal/incomplete, or if everyone is using a windowing library. Maybe just remove it and see if anyone complains?

[mohawk2]

@nrdvana Thank you!

I can't find anything to actually remove - Modern.o (which is nearly 6 megs) has no symbols with glX in (as shown by nm). I think this issue is moot, so I will close it.

If users need OpenGL::GLUT or OpenGL::GLX, those exist in the legacy OpenGL distro. My recommendation to them would be to use GLFW, but that doesn't need mentioning within this module/distro.