Menu
I just had a read through Loading OpenGL Functions and wondered why OpenGL is designed that way, instead of the easy way, providing a dynamic library and the according headers?
533
OpenGL (Open Graphics Library) is a cross-platform, hardware-accelerated, language-independent, industrial standard API for producing 3D (including 2D) graphics. Modern computers have dedicated GPU (Graphics Processing Unit) with its own memory to speed up graphics rendering.
Glad is able to generate a debugging header, which allows you to hook into your OpenGL calls really easily using glad_set_pre_callback and glad_set_post_callback, you can find a more detailed guide on the github repository.
The OpenGL Extension Wrangler Library (GLEW) is a cross-platform open-source C/C++ extension loading library. GLEW provides efficient run-time mechanisms for determining which OpenGL extensions are supported on the target platform. OpenGL core and extension functionality is exposed in a single header file.
providing a dynamic library and the according headers?
Then you have a misunderstanding of how a "dynamic library" works.
Let's take Windows as an example. On Windows, if all you had was "a dynamic library and the according headers", you would still be unable to just load that DLL and use it. Even the use of __declspec(dllimport) declarations in the header is insufficient. You need one more thing: an import library. This is a .lib that effectively does the job of loading function pointers for you when you load that DLL.
In short, it's syntactic sugar: nice to have, but not essential. A lot like an OpenGL Loading Library.
On Linux, things are a bit different. SO files are more self contained; they basically store the equivalent of an import library within them. So there, you could in theory get by with "a dynamic library and the according headers".
Even so, it's still sugar; you can dynamically load them and fetch function pointers manually if you wish.
All of that sugar theoretically could be used with OpenGL. But let's think about the ramifications of that.
On Windows, the import library is statically linked to your application. Therefore, it must work; if it fails to find the DLL, or that DLL does not provide the functions it ought to, then your program cannot run. At all. That's what most of those "missing DLL" errors are about; some static import library trying to find a DLL that doesn't exist.
So... what if I want to write an application that uses OpenGL 3.3 as a minimum, but is able to use features from OpenGL 4.5 if they are present? I can't link to the OpenGL 4.5 import library, since it'll fail to load on amy 3.3 implementation. So I have to link to the import library for OpenGL 3.3. But then, how do I access the 4.5 functions? That's right: I have to load function pointers if they exist.
So most people are going to have to load some functions anyway. It's much cleaner to just load the whole thing. That way, you don't have to have versioned import libraries.
Also, by loading all OpenGL functions dynamically, you don't have to wait for your OS vendor to update their DLL before you can use the next set of OpenGL functions. The main DLL simply provides a connection to the IHV driver DLL (or Open source driver on Linux) that actually implements OpenGL.
Note that Microsoft's OpenGL32.dll still only provides OpenGL 1.1. So I'd say we've benefited from not waiting on them ;)
Also, we have "the easy way": use an OpenGL Loading Library.
55
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
