I am trying to render offscreen to then retrieve the result in a Java image to display it in any canvas (AWT/Swing/JavaFX/SWT). Should I rather use Pixel Buffers on Ubuntu? (hopefully not!)
You should use the actual OpenGL framebuffer object feature, not EXT_framebuffer_object extension functions. I don’t know why you’re using those on MacOS anyway, since whatever OpenGL implementations exist on the platform provide the core feature.
Basically, there’s no reason to be relying on these functions to begin with.
The framebuffer object is unfortunatelly not available on my Ubuntu neither on my Windows. What is surprising is that I find GL_FRAMEBUFFER but not glGenFramebuffers from glut.h.
Looking more in depth, I found glGenFramebuffers in glew.h. I would expect this to be in gl.h as the spec says it is available as of GL3 and as glxinfo says my computer supports GL 4 :
I was able to follow your recommendation on my macOS though; so roughly deleting all EXT and the FBO works perfectly.
One additional question : should I expect the GL_EXTENSIONS listing to be unreliable? Finding GL_EXT_framebuffer_object shouldn’t mean that glGenFrameBufferEXT will be available?
Concerning my original mistake I’ve followed code samples from there without seeing these are too old (thought mentionned at first line :D).
That should not be surprising as GLUT provides an abstraction over platform specific window system interfaces, it has very little to do with accessing gl functions or extensions - those tasks are the handled by loading libraries.
Nope, sorry, that’s an incorrect expectation. Only GL 1.1 interfaces are exposed through gl.h higher versions and extensions are exposed through GL/glext.h, see the registry for details.
Additionally the GL shared library that you link with exposes only GL 1.1 interfaces for direct linking on some platforms, and all higher versions and extensions must be accessed through function pointers obtained with {glX|wgl}GetProcAddress; → loading libraries.
Are you calling glewInit and are you doing it at the correct place (after creating the GL context)? Do you have an old version of glew that requires a little help when used with a core profile context: see here.
What I do is generating Java binding based on the content of a anything.h file, usually glut.h or freeglut.h. It seams Apple made glGenFramebuffer available in glut whereas other manufacturers did not.
So when I say "I can’t find glGenFramebuffer", it means the generated Java code misses it, either because it was really lacking in the glut.h file I chose for binding generation, either because it may require a more complex loading scenario as you mention ( {glX|wgl}GetProcAddress).
I’ll try to find a more complete example of using framebuffers through GLEW, GLEXT or GLFW (I’m little lost who’s the best at providing it on Windows and Linux). If you know some, I’ll be glad to refer to it!
To answer your question, my glew is provided by Ubuntu 20 so I think it is recent.
There are xml files in the OpenGL registry that describe the API and also the python scripts that generate the C headers from those files - using the xml files as basis for your Java bindings could help avoiding header differences between platforms. Also, I assume you are aware of existing Java bindings?
Yes, I am a seasoned user of JOGL and jGL that I both incorporated in Jzy3D, a Java toolbox for data visualization. I am working on extending JOGL to support future versions of the JVM (>=17) that both offer new way toward native bindings (project Panama), and potentially close the doors to the existing ones.
Project Panama offers native bindings for generating callers to native libs. I plan to use the registry you mentioned to generate a unified java class design on top of such panama generated callers, somehow similar to what JOGL developers did in the past.
I indeed found glxGetProcAddress but it’s the first time I see this pattern. If you have in mind a sample showing how to use a frame buffer using GLX, hence loading the glGenFramebuffers function dynamically (which I understood I should do), that would be very handful to me to get it.
Many, many thanks for your enlighting answers up to now, you really helped me a lot!
That’s how pretty much every C and C++ program interacts with OpenGL. They load the addresses of function pointers manually. Most programs use dedicated libraries for this purpose like GLEW or GLAD. There is nothing specific to “[using] a frame buffer” with regard to that; the function pointers are loaded the same way.
No, it’s pretty much the way every C and C++ program that needs to run on Microsoft Windows interacts with OpenGL.
If you only need Linux support, you can just link with the GL libs and get the symbols the normal way (compile-time linking). Unfortunately, this is not really possible on Windows. Thus wglGetProcAddress() and extension loaders that handle all this big block of dynamic function pointer querying logic for you.
glut.h typically includes gl.h. gl.hmay include glext.h automatically. Similarly, linking against libglut will automatically pull in libGL to resolve imports from libglut itself, but that may or may not be used to resolve imports from the main executable (it depends upon the linker and its options).
The main use for glXGetProcAddress is if you want to use new features if they’re available while still running on systems which don’t have them. If you import a symbol directly, the executable simply won’t load on any system where libGL lacks that symbol. If you obtain the function pointer via glXGetProcAddress, the program will run regardless of whether that function is available. You can’t just use the return value of glXGetProcAddress because the function may exist in the library but not be supported by the display driver or X server; you have to test the client and server OpenGL versions and/or the extension list.
On Linux, glXGetProcAddress is functionally equivalent to using dlopen/dlsym. On Windows, the situation is more complicated. If you have a multi-head system using video hardware from multiple vendors and the application has multiple windows (which could be on different displays), you have to call wglGetProcAddress for each window as each display will be using a different OpenGL driver and you’ll get different function pointers for different displays. On Linux, dispatch is handled by the system OpenGL implementation (unless you’re using Nvidia, who provide their own libGL which bypasses all this).
I suggest using glcorearb.h which is available from the registry. I use it for a cross-platform application I have running on Android, iOS, Linux macOS and Windows. (The app does use glew.h on Windows when creating its context but that is only because it uses glew to load GL function pointers.)