Speaking of idiocy, a screen saver for the iphone? Jeez!! What a waste of talent and battery.
I do agree with the sentiment that APIs should be deprecated over time.
If you were involved in the OpenGL ES specification, you are an idiot
201–210 of 225 posts
Re: If you were involved in the OpenGL ES specification, you are an idiot
#202Earlier quoted context omitted.
OpenGL ES is for "embedded systems" which basically means phones. That means inefficient programming drains the battery. Sure if jwz want's to punish his user's I guess that's his prerogative but it seems like a good decision to provide an API that discourages bad practices. Basically they decided to get rid of the cruft. OpenGL 1.x was designed in 1992? GPUs fundamentally changed in the mid 2000s and the decisions m…
The iPad graphics subsystem absolutely destroys anything around when the OpenGL spec was released and many of these screen-savers were designed against hardware that's unbelievably slow compared to an iPad. He's not making a game that's going to drain the battery in ten seconds flat, he's porting screensavers made in the late 1990s that were never heavy-duty to start with.
Sure. But OpenGL ES was not designed for the iPad. The decision to reject immediate mode was made in 2003, for the mobile devices of that time. And it is used in the industry for devices much less powerful than the iPad, even today.
It continues to be a popular choice for anything like the iPad, where there is no legacy software based on regular OpenGL, because it is a much cleaner and much easier to implement stack, and because if you are writing new software you should never be using all of that old deprecated cruft anyways.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#203Earlier quoted context omitted.
What earlier version? GL ES is NOT GL.
That's why it's bothering a lot of people that it has "GL" in the name at all.
Why? It's basically a subset of GL, what's wrong with that? It's a bit like complaining that XHTML Basic profile is incompatible with the full XHTML.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#204Earlier quoted context omitted.
* It costs money to document. * It costs money to implement. Three days for a lone coder, much more than that for a careful consistent development process. * It costs money to develop regression and validation tests. * It costs money to test, including collecting all the different hardware it needs to be tested on. * It costs money to fix bugs in it. * It costs money to answer questions from developers about it. * Th…
While that's all true - it completely ignores the externalities. It cost Jamie 3 or 4 attempts and eventually 3 days work to get his unbroken code running on the new OpenGL version. What's the multiplier needed to account for the cost this change incurred for all the other developers who wrote code using OpenGL before ES? Sure, maintaining backwards compatibility is costly for a project like OpenGL. But if you choose…
This is a good question, and if you look a few posts up I started this comment tree by addressing it:
> if we compare the massive number of newly written OpenGL ES applications to all the old OpenGL 1.x fixed pipeline apps, the latter seem insignificant.
It was a design judgment they made and I think it was the right one.
> by reimplementing the old API calls in 3 days
JWZ did not produce a complete production-quality set of OpenGL 1.x compatibility APIs in 3 days. I'm going to guess without looking at his code that he didn't even write regression tests for the calls that he did implement.
What JWZ did was 3 days of possibly great coding, but that's only a tiny part of what needs to be done to ship new APIs in something like OpenGL.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#205Earlier quoted context omitted.
* It costs money to document. * It costs money to implement. Three days for a lone coder, much more than that for a careful consistent development process. * It costs money to develop regression and validation tests. * It costs money to test, including collecting all the different hardware it needs to be tested on. * It costs money to fix bugs in it. * It costs money to answer questions from developers about it. * Th…
While that's all true - it completely ignores the externalities. It cost Jamie 3 or 4 attempts and eventually 3 days work to get his unbroken code running on the new OpenGL version. What's the multiplier needed to account for the cost this change incurred for all the other developers who wrote code using OpenGL before ES? Sure, maintaining backwards compatibility is costly for a project like OpenGL. But if you choose…
> While that's all true - it completely ignores the externalities. It cost Jamie 3 or 4 attempts and eventually 3 days work to get his unbroken code running on the new OpenGL version. What's the multiplier needed to account for the cost this change incurred for all the other developers who wrote code using OpenGL before ES?
This is ignoring an awful lot of reality. Like, that OpenGL isn't a project that ships one software stack, but a standard managed by a group and voluntarily implemented by graphics vendors.
The Khronos group exists to negotiate between vendors and create a spec they're willing to implement, not to dictate to them a spec they hate and will ignore. There was a near riot when the OpenGL (non-ES) 3.0 was announced; many vendors were seriously pissed off that it didn't drop Immediate Mode and the the fixed pipeline and that they had to sink enormous amounts of time into writing and maintaining a compatibility layer on top of modern GPUs for shit that had been deprecated for damn near a decade. That meant not just writing an Immediate Mode shim for a tiny subset of OpenGL 1.3 like JWZ (and like countless other have done in the past), but doing shit like generating shaders on the fly based on the current state of the emulated fixed function pipeline, and making sure to cover all of the bizarre corner case interactions between all of that old fixed function garbage and threading and any new calls the program happened to mix in.
Vendors were ready to walk away from OpenGL over this. That's why the OpenGL 3.1 spec dropped the fixed pipeline like a hot potato and doesn't require that vendors ship a compatibility profile for the old crap.
Now, what if, back in 2003 when the decision to not include this stuff in OpenGL ES 1.0 was made, they'd released a spec requiring mobile vendors to do the same thing? What would the cost to JWZ and his project, and all other developers who wrote OpenGL before ES, have been if the mobile vendors had collectively told Khronos to fuck off? If OpenGL ES didn't even exist as a target for a shim, because there was no way in hell mobile vendors were going to ship a multi-meg driver that had to generate code on the fly, on the off chance anyone ever wanted to ship AutoCAD for hardware that barely had enough RAM to fit the driver?
Because there was certainly no guarantee, at the time, that OpenGL ES was going to become the standard for mobile graphics. It happened only because the standard that was proposed was something that the vendors were willing to ship.
> Sure, maintaining backwards compatibility is costly for a project like OpenGL. But if you choose _not_ to maintain backwards compatibility, for whatever reason, and then someone shows that your reasoning is bogus by reimplementing the old API calls in 3 days, you should expect to get called "idiots". (And you then should either be sure enough in your convictions that you know jwz is wrong, or take it on the chin and say "Hey, we fucked _that_ one up. Mind if we include your code in our next release?")
Oh come off it. He didn't reimplement ALL of OpenGL in 3 days. He reimplemented the tiny subset of calls, with the precise semantics (and only the precise semantics) his program needed, in 3 days. That's a far cry from shipping the entire behemoth that is a fully back-compatible OpenGL stack. And he's not the first guy to do this, or the 5th. I've got books on the shelf behind me with small Immediate Mode shims in their appendixes for people who want to do it "the old way". I've seen code to do it in forums and in repos. It's dead easy.
The Khronos group doesn't see this shit and think "damn, we fucked up". They think "Good. We gave vendors a decently small spec that they were willing to implement, allowing OpenGL ES to become the standard in mobile graphics, but we still managed to base it on well-chosen primatives that people like JWZ can use to build higher-level interfaces around if they choose".
Re: If you were involved in the OpenGL ES specification, you are an idiot
#206Earlier quoted context omitted.
No, I understand that point. I just don't agree with it in this case. * "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 archite…
"Sorry JWZ, but your X screensaver project is actually not an overriding concern driving the evolution of OpenGL ES." Seriously, if you think that's a valid response, then you did not understand his point. Repeating something does not make it any more valid an argument.
OK I re-read his post. I think I understand his point. He has a something of a valid point, but what he is raising are considerations, not overriding principles.
If he wants to write his code by treating these as "thou shalt not" type laws, that's fine. He can criticize others for not following the same principles. But calling a bunch of top graphics engineers "idiots" because they looked at a vastly different engineering problem with different priorities and arrived at a different design is rude and ignorant and it reflects poorly on JWZ.
JWZ makes this statement: "Your users have code that works."
He is simply wrong about this.
* No one had working OpenGL ES code before OpenGL ES was standardized. This is by definition and one cannot argue the definition of OpenGL ES with the OpenGL standardization body itself.
* Even if you wanted to accept the mistake of thinking of the existing OpenGL 1.x codebase was supposed to be forwards compatible with ES, it's not true in the main. The amount of existing OpenGL 1.x that could plausibly benefit from being ported to embedded devices is insignificant. Seriously, JWZ may have just ported most of it.
This is what I mean by "X screensaver project is actually not an overriding concern driving the evolution of OpenGL ES."
JWZ seems to think that his principles of software engineering are the only correct way to look at it. He goes so far as to say "If you don't agree with that, then please, get out of the software industry right now. Find another line of work. Please."
To support such absolute claims and broad sweeping statements he uses a toy porting project that takes three days. The vendors who participate in the OpenGL ARB are concerned with projects that take 3 years and APIs that persist for more than 20! Don't you think they actually might know a thing or two about APIs and engineering them for software? Don't you think they might know extremely well what the costs of failed backwards compatibility are?
But that's OK, everybody scratches their head for a bit trying to sort out the different flavors of graphics APIs. Even single-vendor Direc3D has similar issues. If this is the most confusing thing about OpenGL to him and he can do something useful with OpenGL ES in his first three days of messing with it, he is a really really smart guy.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#207The thing that particularly bothers me about this post: > People defend this decision by saying that they "had" to do it, because the fixed function pipeline is terribly inefficient on modern GPUs or some such nonsense. These people don't know what they're talking about, because the contour of the API has absolutely fuck-all to do with what goes over the wire. As far as I can tell from what he's written, all he's don…
And what I've understood he's done is not to retransmit static geometry every single frame, but to use an array to send batches behind the scenes. This is, the exposed API doesn't force any particular implementation. And that makes a lot of sense.
If he's reimplemented the OpenGL 1 API, then he must be retransmitting geometry every frame, because the API is not sufficiently expressive to allow for retained state of that nature. He describes glBegin and glEnd as accumulating an array to batch out, but that batch gets re-accumulated and transmitted every single time the glBegin/End block is executed, i.e. every single frame.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#208Earlier quoted context omitted.
This indicates a fundemental misunderstanding of OpenGL ES. It cannot break working code by not having OpenGL 1.0 features, because OpenGL ES is not a revision to or successor of OpenGL 1.0. Note that OpenGL 4, which is a (distant) successor to OpenGL 1, does include OpenGL 1s features, marked as deprecated.
OpenGL > 3.1 does not require implementation of compatibility profile, which includes deprecated funtionality. OSX doesn't.
Awesome! I wasn't aware that had become optional.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#209Earlier quoted context omitted.
Cars are switching from petrol to hybrid to electric motors, but roads still work... "Rapidly developing" is a red herring.
> Cars are switching from petrol to hybrid to electric motors, but roads still work... Yes, and this is what makes this a bad analogy.
He's got the whole analogy inverted. If roads were rapidly changing, we'd need dramatically different cars to handle the new roads.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#210Earlier quoted context omitted.
I think if you focus on the win{16,32} API, it doesn't do any justice to, for instance, the C library. FreeBSD has always supported binaries from various UNIX systems and I think this heritage goes back a bit further then 1995. Also, windows bundles a c library of its own which implements a significant subset. Sure win{16,32} support a GUI with bells and whistles but that's because it evolved several years later spec…
You misunderstand my point about length. I'm completely aware that there are plenty of APIs that have been supported far longer than Win . That's not what I'm talking about. What I'm wondering is this: Has there ever been an API with a longer deprecation period than Win16? Remember, Microsoft announced the deprecation in 1995 (IIRC), but it didn't start to bite until 64-bit Windows mattered (you could draw the line a…
X11: 1987.
Still works in 2012.