Many thanks for these pointers!

I am aware that GLUT is somewhat outdated. But then - OpenGL as a whole is about to be spelled Vulkan today. The funny thing is that GLUT still works fine, and it fits the OpenGL Programming Guide quite nicely. This ~15 year old guide comprehensively covers OpenGL and window management. I'll definitely try GLFW and its Perl module. I'll also check out your X11 module and the Sandbox.

Installing OpenGL::Sandbox from CPAN on my Machine (Debian bullseye) gives one test failure:

This might be an issue of my box because the CPAN Testers Matrix for OpenGL::Sandbox is clean.

BTW: I also tried OpenGL::Modern and was not convinced. It seems to cover "modern" OpenGL, but it needs some guessing around which export tags are needed for which interface, which interfaces are available and how interfaces using C pointers need to be rewritten. Plain old OpenGL comes with an examples directory which got myself started, the "Modern" thing has nothing like it, not even tests to steal from.

The CPAN testers matrix for OpenGL::Sandbox can be misleading because it can use either OpenGL or OpenGL::Modern, and when it uses OpenGL it skips some of the tests because (for example) buffer objects aren't available from the OpenGL module.

I just checked with my current install of 5.36, and t/35 and t/36 are both crashing. I'll take a look at it. If you aren't using new stuff it won't matter for you.

I agree that OpenGL::Modern is less friendly. The author took a more "exactly the same as the C API" approach, and while that makes it easier to port C code to Perl, I doubt anyone wants to write C code in Perl if Perl isn't adding "friendly" wrappers. That was sort of why I made the OpenGL::Sandbox. If you look at the source code of the shadertoy script, it is massively simpler than the corresponding C code, and a lot safer than manipulating raw pointers in Perl.

The downside of modern / shaders is that I never wrote a Font module for it. So, the only way to get text is to use ::V1 and the matrix stack and all that.

Thanks for the clarification regarding the Sandbox tests!

I don't mind a "exactly the same as the C API" approach, but this then needs some explanation of how to deal with interfaces which expect a pointer to a C array like e.g. glSelectBuffer. OpenGL populates this C array, and I need a way to examine the results.

I guess OpenGL::Modern can be used together with OpenGL::Array in the same way as it is used with OpenGL, but I have little motivation to try it.

Also, I should mention that my focus isn't on shaders. While I know that they can provide amazing effects, I am happy with the "basic" stuff which is in plain old OpenGL. What I'm after is interaction with drawn shapes. Tk::Canvas provides this: I can add callbacks to individual polygons and tag them appropriately so that all primitives which make a complex shape have the same tag. Only this approach is getting painfully slow if I have tens of thousands of primitives. OpenGL has a different approach for this: Normal rendering is done without any callbacks. After a mouse click, I can re-render a tiny part part of the scene (e.g. a 5x5 pixel area around the point where the click happened) and OpenGL will tell me what objects were on the way.

Plus, of course, most of the drawing is done by the GPU (which is, btw, the part also done by Tk::Zinc). This gives amazing speed, which is why I don't want to try the two-step approach of interactivity (i.e. redraw a tiny area after a mouse click) in plain Tk.

buffer objects aren't available from the OpenGL module

But they are (as an "extension)! I did some research before starting with OpenGL and found the wikipedia article Perl_OpenGL. I got the POGL Sample Test App linked from there working. Understanding that code, on the other hand, took some time, and I would have surrendered, but then I found the ancient guide.

The example does not work with OpenGL::Modern which no longer provides glGenBuffersARB_p.