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

31–40 of 225 posts

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

#31

Post by Ralith »

qdog wrote: post #9

People that don't study history are doomed to repeat it, or something like that. There's pretty much no reason to drop the old API calls, if you don't want it clogging stuff up, fine, make a separate library you have to throw a flag for or something. Favorite quote: "If there are old features that you would like to discourage the use of, then you mark them as obsolete -- but you do not remove them because thou shalt…

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.

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

#32

Post by ktizo »

hermanhermitage wrote: post #22
ktizo wrote: post #12

Earlier quoted context omitted.

An incremental only approach to design is non-design in my view. Nearly all design is incremental. That's how design works. That's partly why chairs are still recognizably chairs, and other useful stuff like that.

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

true. I think I read your meaning wrong anyway.

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

#33

Post by nvoorhies »

Ralith wrote: post #26
rachelbythebay wrote: post #19

One committee, ten years. One jwz, three days. This is the stuff "10X" is made of.

You're comparing completely incomparable tasks. JWZ did nothing but write a thin wrapper. The committee didn't omit such a wrapper because they couldn't accomplish it, they ommitted it as a deliberate design decision .

Exactly. Forcing every embedded device that wants to do portable 3D to include megabytes of wrappers for over a decade of cruft wasn't worth it, when the alternative is people having to spend a few days' time if they can't find a suitable shim already written somewhere.

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

#34

Post by Ralith »

recoiledsnake wrote: post #18

Related interesting read if you haven't, the brouhaha a few years ago over OpenGL 3.0 preferring to support CAD/CAM programs over games. http://www.tomshardware.com/reviews/opengl-directx,2019.html

I've heard that since OpenGL 3.2 most of the issues that caused that drama got resolved. Does anyone know details?

Edit: Reading parent's link, it looks like there were two complaints: First, OpenGL 1 era features haven't been completely removed--merely marked deprecated, as JWZ loudly advocates. Second (and this took up most of the article) OpenGL 3.0 was not feature-competitive with DX11, which is a bit silly, given that DX11 wasn't available at the time. As of the present day, and as far as I know for most of the recent past, the latest version of OpenGL has maintained feature parity with current hardware and therefore DirectX.

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

#35

Post by kmm »

>If there are old features that you would like to discourage the use of, then you mark them as obsolete -- but you do not remove them because thou shalt not break working code. > If you don't agree with that, then please, get out of the software industry right now. Find another line of work. Please.

Arrogant and wrong. There was no working code in the first place, OpenGL ES is not OpenGL.

I, for one, am very glad with the changes the OpenGL board made. The glBegin/glEnd combo is so inane it should have been removed ages ago. Maintaining all these outdated codepaths carries its cost and clutters up documentation.

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

#36

Post by msbarnett »

mey wrote: post #10
drivebyacct2 wrote: post #7

Earlier quoted context omitted.

Isn't that precisely what he did here? (note, I know nothing about nothing when it comes to graphics/OpenGL stuff)

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)

> I believe the authors original point is why not provide the shim support as part of OpenGL ES in the first place?

OpenGL ES isn't intended to be the same API as OpenGL, despite the shared "OpenGL" in the name. It was a new API created with the idea that it would be based on the lessons learned from OpenGL, but be completely modern and not bogged down with the need for embedded driver authors to waste time implementing tons of legacy crap calls that nobody in their right mind should have been using for the last 10 years anyways. It uses the opportunity afforded by building a new API for a different target environment from normal OpenGL as an excuse to make all of the breaking changes that everybody would love to make in regular OpenGL if only there weren't so much legacy software that depended on the presence of deprecated, decade out-of-date practices.

That's why OpenGL ES never contained all of the immediate mode cruft from OpenGL, and OpenGL ES 2.0 throws out the fixed-function pipeline altogether.

Why didn't the Kronos group define a shim to begin with? When your goal is to build a new API that throws out all of the shit legacy calls that are a bunch of pain to support for no benefit, what do you gain by then re-implementing all of those shit legacy calls again? Any number of people have built a fake immediate mode on top of OpenGL ES over the years; there's nothing new about what jwz did here. If you really want to write OpenGL ES as if it's 1998's OpenGL, there's nothing stoping you from doing so.

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

#37

Post by phillmv »

codedivine wrote: post #5

Much respect to JWZ, but I don't agree here. I am not even sure what to say, except that he is wrong, so I will just leave it there. And no, I was not involved in anyway with GL ES specification.

The above comment is not particularly useful, interesting or relevant. Neither is this one.

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

#39

Post by rys »

hermanhermitage wrote: post #20
mey wrote: 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…

Warm fuzzies for calling us Videologic instead of Imagination or PowerVR. Your description of the layers between an application and execution on the graphics core on iOS is pretty good. There's nothing between driver and hardware though.

As for why OpenGL ES is different to OpenGL, it's documented in myriad places. The resulting API might be bad in many ways, but it was never designed to allow easy porting of OpenGL (at the same generational level). It was designed to be small, efficient and not bloated, to allow for small, less complicated drivers and execution on resource-constrained platforms. It mostly succeeds.

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

#40

Post by Ralith »

katabatic wrote: post #16
hermanhermitage wrote: post #3

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…

Core APIs and languages do not expand at an "unfathomable rate". How long as the Berkeley sockets API been with us? TCP/IP? Twos-complement arithmetic? Do you honestly think that those are going to go away for the sake of some vaguely hand-waved "wider implications" and "idea promotion"? OpenGL has been, like it or not, the only open, widely-adopted, non-proprietary 3D graphics API around for quite some time now. Ena…

But OpenGL ES does not enable OpenGL on mobile devices; that's the entire point of its existence. It enables OpenGL ES, which is intentionally designed to be a simplified subset.

If mobile device manufacturers feel that full-on OpenGL is appropriate for their device, then they are free to implement full-on OpenGL. JWZ should be complaining to the manufacturer, not the spec authors.

I believe that on modern hardware, OpenGL proper is simply OpenGL ES style features (and then some) with a software compatibility layer.

Post reply on HN