[AKluge]

No, WebGL is not a 2D API. Neither is its predecessor, OpenGL. This comment from the article is particularly misleading.

> OpenGL is at its essence a 2D API. The vertex shader accepts something as input and it produces 2D vertices in device coordinates (-1 to 1) as output.

This, and some of the comments in this thread, perhaps stem from a misunderstanding of the projection matrices. The projection that you do yourself is a projection from a large, arbitrary, 3D space to a small 3D space where x, y, and z are restricted to [-1, 1]. These are the device coordinates (http://www.vizitsolutions.com/portfolio/webgl/normalizedDevi...). The hardware is very good at projecting this small 3D space onto the screen.

Indeed, it is possible to write a 3D program entirely within the device coordinates. This example draws two triangles, without any projection, where one is clearly behind the other. http://www.vizitsolutions.com/portfolio/webgl/translationMat... Drag the slider to see one triangle move behind the other.

Even this is a simplified explanation. There are a lot more details here, including all the math: http://www.songho.ca/opengl/gl_projectionmatrix.html This shows why the output from a vertex shader, gl_position, is a vec4. It is definitely not a 2D value.

That said, yes, WebGL is great :)

[ajross]

I think the point was that the OpenGL framebuffer is ultimately a 2D space. Whatever your input data and computation model, at the end of the data the output from your computation goes into a set of arrays with two index coordinates. That's a fairly specious point, maybe, but it's not wrong.

[jmts]

But surely since the memory that the frame buffer is encoded into is 1D, OpenGL is really one-dimensional. /s

Sure, the frame buffer is 2D in the end - it has to be, in order to display on a standard computer monitor - but surely the fact that OpenGL is able to natively handle point data as 3D-homogeneous coordinates, and support for techniques like depth buffering out of the box counts for more than any argument that only really amounts to "after it is finished doing all its work you just have a 2D image".

[jonbronson]

Sure, ultimately most rendering is about producing 2D images as output. But the whole OpenGL pipeline is designed around taking 3D data, and providing abstractions to enable that rendering. Rasterization and depth sorting are only one piece of the rendering pipeline. Of course it's also possible to drop the z coordinates, or use orthogonal projections, to use OpenGL in a purely 2D way. Plenty of applications do that, but that doesn't make the API 2D. It just makes the use case 2D.