Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

jwz.org

Post reply on HN
Print view View original

101–110 of 225 posts

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

#101

Post by bigiain »

saurik wrote: post #89
fpgeek wrote: 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…

" … but to instead encourage third parties to distribute such libraries."

What _I_ took away from jwz's rant (and agree with), is that if providing backwards compatibility to existing users is something one guy can do in three days (including doing the research to find out exactly what's getting taken out of an API), then it seems entirely reasonable to expect a "well behaved" standard like OpenGL to have provided the 1.3 emulation library themselves. Second best would be have a well defined deprecation period with appropriate warnings to developers, which they also failed to do according to jwz, or did properly in OpenGL 2.0 according to you. Whichever of you is right there doesn't _really_ matter much, since it's arguing over whether they got the "second best" thing right, when they seem to have failed at the "right" thing.

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

#104

Post by ecaron »

hesdeadjim wrote: post #64

God what flamebait, how is this near the top of the front page? 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…

> God what flamebait, how is this near the top of the front page?

Because the source is widely respected and has an amazing demonstrated grasp of what good programming involves.

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

#105

Post by greggman »

bigiain wrote: post #101
saurik wrote: 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…

" … but to instead encourage third parties to distribute such libraries." What _I_ took away from jwz's rant (and agree with), is that if providing backwards compatibility to existing users is something one guy can do in three days (including doing the research to find out exactly what's getting taken out of an API), then it seems entirely reasonable to expect a "well behaved" standard like OpenGL to have provided th…

It's not something that can be done in 3 days. Fixed function on top of shaders is a PITA. If you want any kind of speed you've got to generate shaders on the fly based on which features you've turned on or off. Otherwise you create an uber shaders that's show as shit.

glBegin, glEnd are shit APIs given how GPUs work now-a-days.

Worse, things like flat shading require generating new geometry on the fly.

Fixed function pipelines suck balls.

OpenGL ES 2.0 FTW!

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

#106

Post by greggman »

ecaron wrote: post #104
hesdeadjim wrote: post #64

God what flamebait, how is this near the top of the front page? 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…

> God what flamebait, how is this near the top of the front page? Because the source is widely respected and has an amazing demonstrated grasp of what good programming involves.

Yes but in this case he's an idiot. Try asking Carmack. Any GPU programmer knows GL 1.x was utter crap. Good riddance.

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

#107

Post by bigiain »

marshray wrote: post #71
semanticist wrote: post #65

Earlier quoted context omitted.

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?

* 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 _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?")

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

#108

Post by greggman »

semanticist wrote: post #65
marshray wrote: post #51

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?

He didn't implement OpenGL 1.3. He ported an OpenGL 1.3 app to OpenGL ES 2.0. There's a HUGE difference.

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

#109

Post by cma »

retrogradeorbit wrote: post #100
semanticist wrote: post #65

Earlier quoted context omitted.

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...

the exact same criticism applies to you. why haven't you posted it to github yet?

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

#110

Post by fpgeek »

psykotic wrote: post #99
fpgeek wrote: post #91

Earlier quoted context omitted.

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…

Oh, I completely agree with the spirit of your statement. And my disagreement over the letter is over the interpretation of an unqualified "Windows 8" (or "Windows 7"), not about the substantive facts.

The reason I went into that level of detail is because I wanted to highlight the insanely long 14-year deprecation cycle. Is that a record for a deprecation that was eventually removed?

Post reply on HN