Live data from Hacker News

If you were involved in the OpenGL ES specification, you are an idiot

jwz.org

91–100 of 225 posts

Re: If you were involved in the OpenGL ES specification, you are an idiot

#91
post #85

Earlier quoted context omitted.

But it's not OpenGL. It's OpenGL ES. Windows 8 is also not Windows 95.

> Windows 8 is also not Windows 95. Windows 8 is backwards compatible with Win32 and even Win16. If it wasn't, there would be hell to pay. WinRT is a somewhat clean break with the Win32 legacy. But that's only required for Metro apps.

To be fair, 64-bit Windows 7 (and Windows 8) don't support Win16 (as I understand it, because you can't sneak real-mode code into x86 64-bit mode the way you can in x86 32-bit mode).

OTOH, let's be clear about what Win16 is. Win16 is an API that Microsoft deprecated in 1995 (not coincidentally, when Windows 95 was released). In other words, Microsoft took 14 years to go from deprecation to significant (partial) non-support.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#92

Earlier quoted context omitted.

Quite true. But there is another word there "only".

I don't think jwz would have had a problem with it if you called it EmbeddedGL or PhoneGL instead of trading on the name of OpenGL. Like jwz I thought "Oh its OpenGL I've got code already that does most of what I want." only to find none of that code worked.

So this whole rant was just about the name having a common substring of three or more characters?

I hope nobody tells JWZ what Linux was supposed to sound like.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#93
post #78

Earlier quoted context omitted.

jwz makes it clear that his deeper complaint is not about removing the cruft per se, it's about removing vast swaths of the API and then continuing to call it "OpenGL". If they'd called it "MobileGL" or some other nonsense, he probably wouldn't have liked the result (based on this rant), but he also wouldn't have complained that they broke working code. EDIT: 'continuing to call it "OpenGL"' -> 'using "OpenGL" in the…

So OpenGL ES (Embedded systems) was not different enough? I actually think OpenGL ES didn't go far enough in the initial spec. ES 1.1 still has alot of the old fixed function pipeline, but then in 2.0 they scrapped it all entirely, opting for a smaller, more modern API. That, to me, was a bad move. I think they should've made the shader based pipeline in 2.0 part of the 1.1 spec.

Interesting. I hear what you are saying.

To contradict everything I've said elsewhere on compatibility - I'm actually in favor of the 1.0/1.1 OpenGL ES standards and would have liked WebGL to offer 1.1.

My self deceiving justification in this instance is that plenty of platforms that can touch the web are still running hardware only capable of fixed function (eg. Intel 945GM).

Fixed function is easy to make safe, and offers a path to leverage 3d acceleration on these platforms that cannot be beaten in software. Sure its not as exciting as 3d with programmable shaders, but it is still useful 3d none the less.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#94

Earlier quoted context omitted.

Quite true. But there is another word there "only".

I don't think jwz would have had a problem with it if you called it EmbeddedGL or PhoneGL instead of trading on the name of OpenGL. Like jwz I thought "Oh its OpenGL I've got code already that does most of what I want." only to find none of that code worked.

Were people really surprised that Java ME, Java SE and Java EE were different APIs around the same core idea of write once, run everywhere?

Re: If you were involved in the OpenGL ES specification, you are an idiot

#95
post #78

I respect jwz, but this is very much a step backwards, and while I appreciate his complaint about breaking existing APIs, this would be for programs near 20 years old targeted at a different platform. 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 cause…

jwz makes it clear that his deeper complaint is not about removing the cruft per se, it's about removing vast swaths of the API and then continuing to call it "OpenGL". If they'd called it "MobileGL" or some other nonsense, he probably wouldn't have liked the result (based on this rant), but he also wouldn't have complained that they broke working code. EDIT: 'continuing to call it "OpenGL"' -> 'using "OpenGL" in the…

[deleted]

Re: If you were involved in the OpenGL ES specification, you are an idiot

#96
post #58

Earlier quoted context omitted.

If your architectures are completely different, you're going to have to break some fucking code. That's just the way it is.

The article showed the opposite. That there was no need to break existing code.

It showed that some existing code with a shim containing a reimplementation of a small subset of OpenGL 1.3 could be made to run acceptably fast on a rather beefy example of 2012's mobile hardware.

It certainly did not show that there was no need to exclude those calls back in 2003 when they were originally not included in OpenGL ES.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#97
post #89
post #78

Earlier quoted context omitted.

jwz makes it clear that his deeper complaint is not about removing the cruft per se, it's about removing vast swaths of the API and then continuing to call it "OpenGL". If they'd called it "MobileGL" or some other nonsense, he probably wouldn't have liked the result (based on this rant), but he also wouldn't have complained that they broke working code. EDIT: 'continuing to call it "OpenGL"' -> 'using "OpenGL" in the…

Right, but again: those are the parts of the API that are already discouraged and downright deprecated as of OpenGL 2.0. If you were developing an app targeting OpenGL 2.0, following what I understand are the best practices for that version of the specification, OpenGL ES will require little to no porting. The problem then, arguably, is not that OpenGL ES is called OpenGL but that OpenGL 2.0 added an entirely unrelat…

OpenGL 2.0 was released in September 2004 (Wikipedia).

OpenGL ES 1.1 (which jwz complains about here) was ratified and publicly released in August 2004 (going back to OpenGL ES 1.0 would only make the comparison worse, of course): http://www.khronos.org/news/press/khronos-group-announces-th...

That's a quite, um, impressive deprecation cycle, I suppose.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#98
post #97
post #89

Earlier quoted context omitted.

Right, but again: those are the parts of the API that are already discouraged and downright deprecated as of OpenGL 2.0. If you were developing an app targeting OpenGL 2.0, following what I understand are the best practices for that version of the specification, OpenGL ES will require little to no porting. The problem then, arguably, is not that OpenGL ES is called OpenGL but that OpenGL 2.0 added an entirely unrelat…

OpenGL 2.0 was released in September 2004 (Wikipedia). OpenGL ES 1.1 (which jwz complains about here) was ratified and publicly released in August 2004 (going back to OpenGL ES 1.0 would only make the comparison worse, of course): http://www.khronos.org/news/press/khronos-group-announces-th... That's a quite, um, impressive deprecation cycle, I suppose.

Touché: I apparently wanted "OpenGL 1.5", not 2.0. This, in fact, undermines part of my argument regarding the major version number. Further, reading through the history and timeline a bit better, I am now concerned I was horribly misinformed. I would just ignore my comment.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#99
post #91

Earlier quoted context omitted.

> Windows 8 is also not Windows 95. Windows 8 is backwards compatible with Win32 and even Win16. If it wasn't, there would be hell to pay. WinRT is a somewhat clean break with the Win32 legacy. But that's only required for Metro apps.

To be fair, 64-bit Windows 7 (and Windows 8) don't support Win16 (as I understand it, because you can't sneak real-mode code into x86 64-bit mode the way you can in x86 32-bit mode). OTOH, let's be clear about what Win16 is. Win16 is an API that Microsoft deprecated in 1995 (not coincidentally, when Windows 95 was released). In other words, Microsoft took 14 years to go from deprecation to significant (partial) non-s…

One major reason there have been 32-bit versions of all Windows releases up to and including Windows 8 is so that corporations big and small will be able to seamlessly continue running their crusty Win16 and MS-DOS legacy applications. If not for that, many companies would not have been able or willing to upgrade. Microsoft could instead have taken a DOSBox or Rosetta style approach. Hopefully they will do that with some future release, so developers will no longer have to worry about 32-bit support.

So, I feel my original statement was accurate in both its letter and spirit.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#100

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…

Except he didn't port his code to OpenGL ES - he ported the missing API from OpenGL 1.3 to OpenGL ES. 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?

And lets not forget he's also unwilling to help people out by uploading his OpenGL wrapper to github (or by extension any revision control system).

http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-t...

Post reply on HN