instead of just adding new extensions to core it might be a good idea to cleanup the cumbersome api. because this is what lacks in opengl: actual evolution.

By jo on 2009-03-16

It's rather odd to say that OpenGL shouldn't follow any other API, yet you also say that OpenGL's decisions are in the best interests of the industry, not one company. I say this is odd because I don't know of the industry you refer to that wants their graphics API to *not* expose useful, powerful, and important hardware rendering features to the user. You also seem to be addressing the wrong problem. The OpenGL roadmap, extensions to core, has never really been the problem with OpenGL. OpenGL has had 3 fundamental problems: 1: The time difference between hardware features appearing and those features being *exposed* across all hardware vendors through OpenGL. In some cases, hardware has languished unused in OpenGL for *3 years* before getting an appropriate extension. This continues to this day; there are several "DX10" and above features that have existed for years and are not exposed by OpenGL in platform-independent extensions. 2: The quality of those extensions. That is not a reference to the quality of the IHV implementations; I am speaking of the extensions themselves. 3: Unreliability of implementations. As much as you like to tout OpenGL's portability, reality doesn't bear this out. It is very often the case that OpenGL code tested on an nVidia implementation will fail on an ATi one, and vice-versa. That doesn't even come close to Intel's virtually unusuable OpenGL implementations for their hardware. A conformance test suite would go a long way in helping the IHVs at least be assured of reasonable conformity among them. ATi also has the stated position of only implementing ARB-class extensions, so vendor-specific extensions that they might be able to implement go unimplemented.

By Alfonse on 2009-03-17