The purpose of this post is not to be rude or argumentative about OpenGL, but instead to highlight some specific issues with it that were instrumental in my move to the Dark Side, and to suggest some practical solutions. I am not speaking from any position of authority or influence here, but I am someone who was frustrated enough in the past to finally take some decisive action regarding my own continued use of OpenGL.
I don't propose to discuss items relating to the future of the API. These are problems that exist now, and - in my opinion - would be better off being tackled now before any further advances are made. This would give a clean and solid baseline to move forward from, instead of trying to patch up the mess that is currently there on a piecemeal basis.
So without any further ado:
Implement driver certification.
Conformance testing is not good enough as it only validates that outputs are correct for given sets of inputs. We all know of implementations that don't have all entry points supported but yet somehow get away with advertising as a certain version. We all know of implementations that don't support all core features of the version they advertise as. Direct3D drivers have WHQL certification, OpenGL drivers need Khronos Group or ARB or WHATEVER certification. Users of a certified driver can then be confident that the driver supports all entry points and features for the version it advertises. Developers can target certified drivers and not have to worry about writing fallback paths for where a feature that should be there isn't (or doesn't work right).
Implement proper capability querying.
As things stand now the only way to get any halfway decent capabilities info is to try something and see if it fails. This is not good enough. At the very least proper capability querying should mean that you can pass an extension string or a #define to a glGetCapability function and get a return of GL_NOT_SUPPORTED, GL_SOFTWARE_EMULATED or GL_HARDWARE_ACCELERATED. Cards that advertise non-power-of-two textures as a supported feature but that don't hardware accelerate them are a perfect example here. Without proper capability querying this kind of feature is USELESS to a developer.
Publish a proper SDK.
This means something that you can download and install, including a good help file, practical examples and tutorials, hints, tips and proper procedures, tools, sample applications, the works. Look at the DirectX SDK and learn from what it does right (as well as from what it does wrong). Full sets of headers and libs for each version on each platform are REQUIRED. Having to go through wglGetProcAddress contortions just to get core entry points DOES NOT CUT IT ANYMORE. These should be automatically handled by a statically linked LIB, so that all the developer has to do is call the damn function where required.
Establish stronger ties to the windowing system.
This means a glAttachToWindow function which takes a window handle or equivalent and creates the required rendering contexts and everything for you. It can be kept reasonably generic in the API itself, with implementation details being left to the driver vendor. Driver certification would ensure that it was done right. It can provide a reasonable set of safe defaults for getting up and running with good performance and quality, and the more hardcore way can be retained for those who want specific precise control.
Accept some impurity or less-than-perfection where it is pragmatic to do so.
Classic example - the use of the "bottom-left is the origin" paradigm throughout OpenGL. This is AWKWARD and DIFFICULT and UNINTUITIVE to USE, no matter how "correct" it may be in terms of classical Cartesian coordinate systems. EVERYTHING else - image editors, Direct3D, even the way you read a book - uses "top-left is the origin". Another example is the glHint mechanism. In theory it's nice, but in practice any glHint may as well translate to GL_DONT_CARE every time, as implementations don't have to honour them. Give us the ability to say "I want this feature to work this specific way".
None of these suggestions need be dependent on any future revisions of the API; there is no reason why all of them cannot be backported to all previous versions. It's a short enough list - only 5 items - but it's my belief that implementing these would make OpenGL a great and rock solid API again. Right now developing on it is Just Not Fun. You spend more time doing workarounds for driver bugs and dealing with awkwardness than you spend doing productive stuff. Back in the days when Direct3D sucked, this was acceptable enough; in fact it wasn't even an issue as the alternative was just so much worse. OpenGL was seen as a great API in those days, and it could be a truly great one again.
3 comments:
I definitely agree, but very much on the parts about just calling a function and having it work, and capability querying. That would be a lot more useful than the deprecation and such they've been doing with 3.0.
http://www.opengl.org/registry/specs/ARB/fragment_coord_conventions.txt
I don't know about the rest of GL 3.2, but at the very least this is a nice start...
Post a Comment