Live data from Hacker News

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

jwz.org

71–80 of 225 posts

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

#71

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?

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

* These costs are multiplied by every future version that will continue to support it.

* These costs are multiplied by the many vendors that will be required to implement it.

* Some of these costs are multiplied by every language that will support bindings to the API.

* It costs code space in embedded devices.

* It costs as much as a vendor wants to spend trying to make it perform as fast as possible.

* It costs conceptual complexity in developers' heads.

* It costs developers when they inadvertently do things the old inefficient way.

* It costs reputation when somebody compares benchmarks of your product using the old inefficient way against another vendor's product using the new recommended way.

* Requirements to continually support it at the same level of performance constrain your choices when developing new hardware.

* Sometimes it costs precious die space which could be better used for other things.

* The inefficiency sometimes increases power consumption and reduces battery life.

* Users are disappointed if every version of new hardware doesn't run the old inefficient code even faster than the previous version.

So if it doesn't have a real need to be there in ES 1.0 then, yes, it is actively damaging and should be thrown out in the rewrite.

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

#72

Earlier quoted context omitted.

Now that smartphones and tablets have respectable GPUs in them, is there any reason why they shouldn't implement the full OpenGL spec?

> Now that smartphones and tablets have respectable GPUs in them, is there any reason why they shouldn't implement the full OpenGL spec? To what benefit? OpenGL ES is basically OpenGL minus all of the bits you really really should have stopped using over a decade ago. Originally all of that crap was culled out because it was only realistic to write new software for such resource constrained devices anyways, so why bu…

[deleted]

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

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

Wasn't there? There were a number of functions he didn't port. He ended up with a subset of OpenGL 1.3. Maybe that subset wasn't worth the effort?

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

#75

Just some numbers, based on my hardware: Lion OS X install on disk: 7GB iOS 5.0.1 install: 1.7GB My MacBook's RAM: 8GB iPod Touch: 512KB MB's disk size: 100GB iPod Touch: 8GB So: Maybe they removed 80% of the API in general because the iPhone/iPod touch is only 10-20% of a normal computer? Something had to go.

jwz is complaining about OpenGL 1.3 support. It might be worth asking yourself what computers were like when OpenGL 1.3 was released (August 2001).

P.S. I'm guessing your iPod touch has 512MB of RAM, not 512KB.

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

#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 name at all' Effectively, he's complaining about a form of false advertising.

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

#79

Earlier quoted context omitted.

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

Wasn't there? There were a number of functions he didn't port. He ended up with a subset of OpenGL 1.3. Maybe that subset wasn't worth the effort?

That's just what OpenGL needs right?

Yet another incomplete ad-hoc extended subset of OpenGL 1.x functionality lacking documentation, regression and performance tests, a stable and committed team of maintainers, ...

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

#80
post #70
post #55

Earlier quoted context omitted.

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.

FWIW, greenscreen (and amber) CRTs used green and amber phosphors; color alignment didn't come into it, right? As I understand it, green and amber because they were cheap.

Correct, alignment was not a factor for single-phosphor tubes.

The eye is not nearly as sensitive to red and blue so those colors did needed higher energies. But I doubt that it was because the phosphors are cheaper. Computer terminals and monitors were very expensive back then, but commercial color television made some of the common components (like phosphors) relatively cheap.

Green was found to be readable and pleasant. It was the most common for IBM equipment (such as the PC monochrome display).

Amber is very visible, especially in bright light. It was popular too.

White was popular with DEC terminals.

Post reply on HN