4 ms·

The issue is also that, since graphics are a performance intensive and ergo low-level task, there isn't really a one-size-fits-all way of wrapping it up in a hi

The issue is also that, since graphics are a performance intensive and ergo low-level task, there isn't really a one-size-fits-all way of wrapping it up in a higher level api. I can't speak for WebGL, but for OpenGL there are various frameworks and such you can use but at the end of the day most people end up needing specific access to the low level guts and you just end up writing your own code to interface with it.

gambler 15y ago
Is there a good reason why such API can't include low-level function and high-level functions for common use cases?
- dualogy 15y ago
  Those exist too. One of the earliest ones still in use today in OpenGL is GLut.
- exDM69 15y ago
  There are several examples where something like this has gone horribly wrong. High level API's for "common use cases" tend to work only for writing one page examples for text books but are completely useless for anything more serious. One example of this is the CUDA API. They have a low level C API, which gives you a good but a little verbose programming API (because GPGPU is complicated). Then there's a high level API where you write the GPU code mixed together with the CPU C++ code. It somewhat worked for the examples in the Cuda manual but was useless for anything else. OpenGL did have a library called GLU that did some high level things such as quadrics (for spheres, cylinders, etc) and tesselation of polygons. It was completely written on the CPU on top of OpenGL. It worked decently for some stuff. Direct3D has also some helpers, f.ex. to do some matrix math and load 3d models. A library like OpenGL is probably best left to be a low level API for a low level task. A high level API in this case would be a 3d engine on top of OpenGL and there are plenty of those out there.
exDM69 15y ago
No, the OpenGL API is a mess. It's not because it's an API to do a complicated task but merely because of it's 1990's legacy. Just compare the OpenGL API to the Direct3D API and you should see a clear difference. The best (or worst) example of this is the OpenGL context, which is basically a global (actually: thread local) variable that tells which GL context and window should be drawn to. This context then stores a bunch of other global state, such as texture bindings. The API was (probably) designed like this because in the early 1990's it was actually a major optimization to avoid pushing parameters to the stack when calling functions several times a frame. Many graphics API's of that era did the same thing. Also there usually was only one screen with one fullscreen "window", so why not make the "display" a global variable? Now 20 years later we are stuck with this shit because it became an industry standard. OpenGL is a pain in the ass, not only for programmers but the implementors of the API. For example, take a look at OpenGL "texture completeness" rules (textures must have consistent mipmap levels, etc). Direct3D does not have an equivalent, because the API is designed so that all textures are always complete. Unfortunately we seem to be stuck with OpenGL for a while. There's not much interest for redesigning the API and as far as I can tell (I'm a Khronos member), no ongoing effort to do so. Direct3D is a much better API but unfortunately it supports a very limited number of platforms (none of which I actually like to use).

gambler 15y ago

Is there a good reason why such API can't include low-level function and high-level functions for common use cases?

dualogy 15y ago
Those exist too. One of the earliest ones still in use today in OpenGL is GLut.
exDM69 15y ago
There are several examples where something like this has gone horribly wrong. High level API's for "common use cases" tend to work only for writing one page examples for text books but are completely useless for anything more serious. One example of this is the CUDA API. They have a low level C API, which gives you a good but a little verbose programming API (because GPGPU is complicated). Then there's a high level API where you write the GPU code mixed together with the CPU C++ code. It somewhat worked for the examples in the Cuda manual but was useless for anything else. OpenGL did have a library called GLU that did some high level things such as quadrics (for spheres, cylinders, etc) and tesselation of polygons. It was completely written on the CPU on top of OpenGL. It worked decently for some stuff. Direct3D has also some helpers, f.ex. to do some matrix math and load 3d models. A library like OpenGL is probably best left to be a low level API for a low level task. A high level API in this case would be a 3d engine on top of OpenGL and there are plenty of those out there.

exDM69 15y ago

No, the OpenGL API is a mess. It's not because it's an API to do a complicated task but merely because of it's 1990's legacy. Just compare the OpenGL API to the Direct3D API and you should see a clear difference. The best (or worst) example of this is the OpenGL context, which is basically a global (actually: thread local) variable that tells which GL context and window should be drawn to. This context then stores a bunch of other global state, such as texture bindings. The API was (probably) designed like this because in the early 1990's it was actually a major optimization to avoid pushing parameters to the stack when calling functions several times a frame. Many graphics API's of that era did the same thing. Also there usually was only one screen with one fullscreen "window", so why not make the "display" a global variable? Now 20 years later we are stuck with this shit because it became an industry standard. OpenGL is a pain in the ass, not only for programmers but the implementors of the API. For example, take a look at OpenGL "texture completeness" rules (textures must have consistent mipmap levels, etc). Direct3D does not have an equivalent, because the API is designed so that all textures are always complete. Unfortunately we seem to be stuck with OpenGL for a while. There's not much interest for redesigning the API and as far as I can tell (I'm a Khronos member), no ongoing effort to do so. Direct3D is a much better API but unfortunately it supports a very limited number of platforms (none of which I actually like to use).