Live data from Hacker News

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

jwz.org

51–60 of 225 posts

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

#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 seem insignificant.

As he so ably demonstrates, it's just not that hard to port the older apps either. This "All you engineers are idiots because I had to work THREE WHOLE DAYS to port this 20 year old code to an iPhone" just sounds childish and silly.

The OpenGL board made the right decision for ES.

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

#52

He probably won't be very happy to know OpenGL ES 2.0 is not backward compatible with OpenGL ES 1.1.

It's common for hardware that supports the newer version to have a driver to support the older versions as well, though. Sort of just like the article did, but faking fixed function hardware using programmable hardware.

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

#53

OpenGL ES is not designed to be OpenGL. It has a different set of constraints. The point is to prune back the API for small devices - NOT - to make make migration of legacy code simple. For sure it would be nice if it came with a client side library to emulate OpenGL to assist in migration where people dont care about foot print size or perf. JWZ is a very smart guy and I respect his opinion, but he is coming from a…

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 burden driver authors and hardware with the need to support crap that should never be used anyways?

Now that mobile device CPU/GPUs are powerful enough to start being appealing as targets for porting OpenGL-based applications, I think the proper response is less "great, slather back on all of the deprecated legacy cruft from the desktop version of OpenGL" and more "for the love of god update your rendering pipeline to reflect the last 15 years of progress".

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

#54
post #10

Earlier quoted context omitted.

I believe the authors original point is why not provide the shim support as part of OpenGL ES in the first place? Stick a big red sticker on it saying here be dragons, but it's obviously not an impossible task. The funny thing is, his shim is actually useful for speeding up code (in theory, this may already be done) on normal OpenGL. (For anything using these interfaces)

Disclaimer: I've dabbled as a driver writer in a past life - but not OpenGL ES. The problem is a 100% compatibility layer is not necessarily easy nor valuable. The makers of OpenGL ES don't want a lifetime of maintaining someone elses problem. Also there is a line where you cross and you lose hardware acceleration and the mapping breaks down. Their charter is to make a new lightweight API that meets the needs of devi…

There actually are PDFs out there for the various GPU IPs on how to write best for them (Adreno, PowerVR, etc.). Sometimes they even disagree, so using triangle strips with degenerate triangles to connect separate portions can be better than using all separate triangles on another, depending on their optimizations. Apple also has recommendations: http://developer.apple.com/library/ios/#documentation/3DDraw...

Although I don't recall off hand if any of them have mentioned sorting commands by state and deduping, which I suppose is one of the most basic optimizations for OpenGL * APIs.

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

#55

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.

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

#56
This guy needs to get over himself. The world doesn't revolve around his pet project.

His rant is stupid for at least four reasons.

First, OpenGL ES is not regular OpenGL. If it were, it would just be called "OpenGL". It's a different thing, based on OpenGL, but targeted at mobile phones and "small" devices. It's almost like complaining that DirectX and OpenGL have different interfaces. They're different things, therefore they will be different. At the time of OpenGL ES's release there was no backwards compatibility to consider, because it was a new thing.

Second, few applications or games used the immediate mode drawing code in regular OpenGL. It's slow and inconvenient to use for the data formats used in real life. It might be great for the OpenGL equivalent of "Hello, World", but other than that nobody uses it.

Third, there was a lot of discussion about what should be in OpenGL ES, and he could have contributed his opinion when the spec was being drafted. Where was his outcry then, when he could have made an impact? Honestly, though, it probably would have been ignored, because immediate mode is so lame.

Fourth, immediate mode is deprecated even in regular desktop OpenGL, as of version 3.0.

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

#57

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"

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

#58

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"

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

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

#60
post #46

OpenGL ES is not designed to be OpenGL. It has a different set of constraints. The point is to prune back the API for small devices - NOT - to make make migration of legacy code simple. For sure it would be nice if it came with a client side library to emulate OpenGL to assist in migration where people dont care about foot print size or perf. JWZ is a very smart guy and I respect his opinion, but he is coming from a…

> In my experience, backwards compatible APIs and languages are what makes development a pain going forward That's the exact opposite of my experience! Libraries that are constantly changing their APIs produce the vast majority of my work.

I think hermanhermitage meant that backwards compatibility makes development painful for the library developer.
Post reply on HN