vispy/vispy — pull request #138 by almarklein (2014-02-26 11:13:10+00:00)
Title: GL backends

Code for our GL backend is auto-generated from `vispy/codegen`. The code ends up in `vispy/vispy/gloo/gl`. The idea that we use the GL ES 2.0 API and have multiple implementations that can be used.

### The backends

There are now 3 backends:
* desktop (our own fast OpenGL wrapper via ctypes)
* angle (via ctypes, Windows only, WIP because need libs)
* pyopengl (use pyopengl functions, for fallback and testing)

Future backends:
* mock (for testing, I might add this to the PR)
* proxy (send OpenGL commands anywhere else)
* webgl (like proxy, but specific for browser)
* Kivy (vispy on mobile?)

### The API

Currently the API is *almost* compatible with the WebGL API. This makes things easier for the backends, but more importantly, it is a very clean API. This means a handful of function names are different with respect to e.g. pyopengl:
* genX -> createX
* deleteXs -> deleteX
* getXiv -> getXParameter
* getBooleanv, getFloatv, getIntegerv, getString -> getParameter

We also decided last week that we use the "gl" prefix. Note that WebGL does *not* use the gl prefix. So we are not *completely* adopting that API. I think this is acceptable. Is eveyone ok with this?

### Extensions and OpenGL 3

Since the [GL ES 2.0 extensions](http://www.khronos.org/registry/gles/api/GLES2/gl2ext.h) and the [WebGL extensions](http://www.khronos.org/registry/webgl/extensions/) do barely overlap, I decided to completely omit the `gl.ext` stuff. The only overlap of interest is the float_textures (not floats on the GPU, but uploading of floats), half_float_textures, and perhaps vertex_half_float extensions. But these only require additional constants, not functions.

This means for instance no 3D textures :( My proposal is to create a `gloo.glplus` (or similar name) that contains everything from OpenGL.GL except for the deprecated stuff and what we cover in `gloo.gl`. We should probably create a new PR for this.

So there should be a clear separation between "bare ES 2.0" that will run basically anywhere, and "advanced GL" that will run on most modern desktops, but using it means no more IPython notebook integration.

### Injection vs proxy

Users (and gloo) can use the `gloo.gl` namespace without worrying what backend implementation is used. But they can also use one of the backends directly, e.g. `gloo.gl.desktop`. To make the `gloo.gl` namespace work, there are two options: 1) [inject (i.e. copy) all functions](https://github.com/vispy/vispy/blob/gl-backend2/vispy/gloo/gl/__init__.py#L65) from a backend; 2) define functions that [call the corresponding function in the selected backend](https://github.com/vispy/vispy/blob/gl-backend2/vispy/gloo/gl/_main.py).

The first option is obviously faster, because its safes one dict lookup and one function call. (Not a lot faster, but measurable nonetheless.) However, in gloo some function objects from `gloo.gl` are [stored at import time](https://github.com/vispy/vispy/blob/gl-backend2/vispy/gloo/variable.py#L140). I can see three options:

1) We use the proxy method and accept the minor inefficiency. (naah)
2) We use both methods, so that function objects stored at import time work as expected, but the rest of the code is fast. (current approach)
3) We modify gloo to store function names at import time and do `getattr(gl, stored_name)` at runtime. (my +1, but we should probably fix this in or after the new-gloo PR)

### Further notes

To make the Angle backend work, we need some way to ship the libraries to the user. We should address this issue in a separate discussion. For the time being, the angle backend uses hard-coded paths and will only work on my machine :)