Hacker News Reader

Comment by rogerbraun | Hacker News Reader

As a counterpoint to the "OpenGL needs to start from scratch" discussion, take a look at JWZs blog about porting XScreenSaver to iOS: http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-t...

View on HN

Indeed. The death of the immediate draw APIs is something that only driver writers and serious optimization wonks think is a good idea. For everyone else, it simply makes ES2 an API that is basically impossible to learn. Without exception, everyone I know who does any 3D work at all learned first on 1.1 doing flat shaded fixed function stuff.

And all those APIs are gone. The amount of code required in ES2 to put anything on the screen at all is staggering.

But that said: the per-vertex APIs really are broken from an optimization sense, and serious apps absolutely must do their work on buffer objects. (Display lists have historically been a way to cheat this, at the expense of huge complexity in the driver. This is one of the bad APIs exDM69 is talking about, I suspect.)

Though they are very handy, they tend to promote a misunderstanding of the pipeline that can hinder later OpenGL work. Learning the modern way right from the start saves a lot of annoyances, especially as the streaming interfaces have some different weirdness when compared with the newer stuff.

Honestly, I view the old GL stuff as a sort of toy language for graphics--and yes, it's annoying to write the boilerplate (oh so much boilerplate) to get a spinning quad onscreen nowadays.

At the same time, if people need a toy language to get into graphics, we really should just write a simple layer on top of modern OpenGL, instead of polluting the API and spec with old garbage.

There is really no use for immediate mode anymore; I'm of the opinion that if you lament the loss of immediate mode, you simply don't want to learn the newer, more efficient ways of doing the same thing.

Ask yourself this, if immediate mode never existed, would you still say that the ES2.0 method is still "basically impossible to learn"? I assure you that it is very possible to learn.

Terminology quibble: you don't mean "immediate mode" in the sense it's been used in the community. OpenGL is still an immediate mode API under all circumstances. There is no scene graph. I probably should have said "streamed vertex" or "begin/end" to make things clearer.

Did you learn ES2 (i.e. create a buffer object, fill it, pass in attribute pointers, goof up the stride values, do it again, draw)? Or did your first triangle come out via begin/vertex/vertex/vertex/end?

My first triangle came out when there was no programmable pipeline, so yep, via immediate mode (any by that I mean begin/end). Then, when OpenGL 2.0 came out, I learned how to use buffers to do it instead.

Are you saying that immediate mode should be used in all cases, even for rendering a complex mesh where you will need to spend CPU cycles iterating and uploading vertices to the CPU every frame?

Goodness no. I think you missed the last paragraph I wrote in the note you responded to.

I'm saying that the begin/end APIs should not have been dropped from the spec in ES2. There needs to be some kind of equivalent, because high performances games and driver writers aren't the only users of the API.

It seems like the API could probably be replicated in glu or glut, so people who just want the fixed pipeline could get it easily.

Sure, it could be. But the problem was it wasn't, so ES2 came out and effectively abandoned huge chunks of existing code the relied on the fixed function pipeline. And they had no answer for what people were supposed to replace it with. Thus the aggrieved flaming from people like jwz who just want to port some software.

Immediate mode is very useful for drawing a single triangle that fully covers the viewport, something that is quite common for any sort of image processing or post processing. In these cases your performance will entirely be limited by the complexity of your fragment shader or by raw fill rate and not by the method you used to submit the vertices to the GPU.

Agreed, and I would also add that the overhead in terms of development time to set up the boilerplate to render this triangle via immediate mode and the newer methods would be comparable.

OpenGL's role in the software ecosystem has changed since GL 1.x was relevant. Back then it was used as a 3D rendering API (with lights and cameras and such). Today it is used as the standard interface to programmable graphics hardware. GL2+ knows almost nothing about "3d" or lighting and is essentially used for drawing triangles, very fast.

If you need a 3D engine, use a 3d engine. If you're writing a 3D engine, you use OpenGL.

OpenGL should start from scratch and change their name and code naming conventions so no-one would be under false illusions that you can take OpenGL code from 1996 and make it work on OpenGL in 2012.

That would have kept JWZ happy and others who complain about the lack of fixed function and immediate mode in OpenGL too.

Btw. once you get past the basics in GL 1.x fixed function, everything becomes /ridiculously/ difficult. Look at how Quake 3 did their "shaders" for example.

Reply on news.ycombinator.com