61–70 of 225 posts
Earlier quoted context omitted.
You kind of miss the point. This is a philosophical argument ILLUSTRATED through OpenGL and a port. To quote, "thou shalt not break working code"
If your architectures are completely different, you're going to have to break some fucking code. That's just the way it is.
OpenGL is a terrible, awful, crufty API, and the reason those methods were removed is that they are comically suboptimal. They do not reflect anything remotely like modern card capabilities, and their use directly causes harm to the ozone layer, kittens, and infants. I'm pretty sure that glBegin() gave a coworker cancer, and the matrix stack has claimed more lives than Kevorkian.
Building a shim to port over old OpenGL 1.3 apps is kind of like translating the Necronomicon into English--possible, of questionable utility, and likely to bring about insanity and demons.
As others have pointed out, OpenGL ES is not intended to be an extension of OpenGL--it was a chance to break out a lot of the dumb cruft that had accumulated into the API. Most of the features he's complaining about are either bad practice or should be gotten rid of entirely.
Compare the length of the API listings for GL 1.x, 2.x, and modern 3.x / 4.x. Remember that the whole thing is a hissing, clanking state machine, and that interactions between functions can be arcane--and threading presents additional issues.
Immediate mode rendering with glBegin()/glEnd()/glVertex()/glNormal/etc. is ugly. Any shim that collects that information still has non-trivial work stuffing it into a buffer, and the overhead of drawing anything with more than a few hundred triangles soon becomes absurd. Worse, this style of programming discourages storing geometry on the card, and that causes additional inefficiency--and trying to use those calls remotely over X causes all kinds of stupid as glx can barely do indirect rendering anyways.
Additionally, we have additional vertex stream attributes available now which are very flexible and don't map onto that anymore. It's time to let go.
~
tl,dr: jwz is complaining about a fork of an API that removed cruft people depended on, but the cruft needed removing. :(
It's not like there's this massive base of OpenGL code just waiting to be ported to embedded devices if there were just a few more API calls. Yes, there's glxgears, screensavers, and handful of open source games. You could probably get some old CAD programs to run on your Android. But if we compare the massive number of newly written OpenGL ES applications to all the old OpenGL 1.x fixed pipeline apps, the latter see…
You kind of miss the point. This is a philosophical argument ILLUSTRATED through OpenGL and a port. To quote, "thou shalt not break working code"
* "thou shalt not break working code". That's not some Universal Code of Software Engineering, that's just something he made up.
* No one in their right mind would expect you could port 20 year old C using OpenGL 1.x code to an iPhone with no effort.
* There are plenty of reasons APIs can benefit from breaking changes. Security fixes, major architectural improvements, platform porting, even general evolution and modernization. The question is always one of cost/benefit, relative pain vs relative gain.
* Sorry JWZ, but your X screensaver project is actually not an overriding concern driving the evolution of OpenGL ES.
* I didn't mention it again because so many other have pointed this out, but this isn't even the same API. OpenGL ES is not the same thing as OpenGL 1.x.
* Changing the major version number is a common and accepted way to indicate breaking changes are present in an API. The OpenGL board went even farther and gave it a different name and a different versioning scheme specifically because it is different.
When your primary argument that the ES designers were idiots is lack of immediate mode, I'm sorry, you are the idiot. These are embedded systems with highly constrained resources and that immediate mode API is horrible for a lot of reasons:
* Requires tons of driver calls.
* Stupidly hard to optimize on the driver side when you have no idea just how many vertices or other per-vertex data are to follow your call to glBegin.
* Trivial to replace with a much better, and much, much higher performing vertex representation either through vertex buffer objects or simple calls to glVertexPointer/etc.
* Teaches beginners the Wrong Way of doing things -- you won't use this API for anything beyond a toy program as the last thing you would do is load an exported mesh from Max or Maya and then iterate through every vertex.
Having learned OpenGL initially with the ES 1.1/2.0 spec, then transitioning back to the desktop version, I couldn't believe how bloated the API had gotten. There is a reason they want to deprecate most of it and move to a spec that is similar to ES in its simplicity.
It's not like there's this massive base of OpenGL code just waiting to be ported to embedded devices if there were just a few more API calls. Yes, there's glxgears, screensavers, and handful of open source games. You could probably get some old CAD programs to run on your Android. But if we compare the massive number of newly written OpenGL ES applications to all the old OpenGL 1.x fixed pipeline apps, the latter see…
If it takes one developer three days to implement the missing API, then perhaps it suggests that this API wasn't in any way damaging to the new system and could have been left in place originally?
If you use green text on a black background you are an idiot.
Green text on a black background is very readable in normal lighting, yet doesn't assault the eyes if you are reading in a darkened room. In addition, there are still people using CRTs. Green on black is often clearer than white on black or black on white, especially in a small font, on CRTs because it is essentially monochrome, and so cannot suffer from fuzziness due to color misalignment.
:) Back in 2008 I helped JWZ port daliclock to the iPhone and once that was working I proposed a port of xscreensaver. He couldn't imagine ever wanting screensavers on an iPhone at the time. Guess he changed his mind. I also was the one that opened his eyes to the differences between OpenGL and OpenGL ES it seems. I apologize.
Ruthless dropping of backward compatibility is a good thing in certain circumstances. I'm not saying this blog post is one of those cases, but for example Microsoft Windows pays a huge price in complexity, cruft, bloat and performance to obsessively maintain backward compatibility. Python 3 has dropped backward compatibility and experiencing significant pain for the decision but after getting to Python 3 it looks arg…
If you use green text on a black background you are an idiot.
Green text on a black background is very readable in normal lighting, yet doesn't assault the eyes if you are reading in a darkened room. In addition, there are still people using CRTs. Green on black is often clearer than white on black or black on white, especially in a small font, on CRTs because it is essentially monochrome, and so cannot suffer from fuzziness due to color misalignment.