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

211–220 of 225 posts

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

#211

Post by koide »

Ralith wrote: post #207
koide wrote: post #168

Earlier quoted context omitted.

And what I've understood he's done is not to retransmit static geometry every single frame, but to use an array to send batches behind the scenes. This is, the exposed API doesn't force any particular implementation. And that makes a lot of sense.

If he's reimplemented the OpenGL 1 API, then he must be retransmitting geometry every frame, because the API is not sufficiently expressive to allow for retained state of that nature. He describes glBegin and glEnd as accumulating an array to batch out, but that batch gets re-accumulated and transmitted every single time the glBegin/End block is executed, i.e. every single frame .

Question from ignorance: Couldn't you internally buffer the geometries and, say, send them to the GPU every 5 frames or so?

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

#212

Post by danudey »

briandear wrote: post #186
psykotic wrote: post #88

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.

Ok Mac OS X Lion is not System 9. And no, Lion isn't backwards compatible to System 9 and there hasn't been hell to pay.

The actual name of the OS changed to 'MacOS' as of MacOS 8.x. The 'System X' designation ended with System 7.5, sadly.

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

#213

Post by msbarnett »

hapless wrote: post #210
fpgeek wrote: post #146

Earlier quoted context omitted.

You misunderstand my point about length. I'm completely aware that there are plenty of APIs that have been supported far longer than Win . That's not what I'm talking about. What I'm wondering is this: Has there ever been an API with a longer deprecation period than Win16? Remember, Microsoft announced the deprecation in 1995 (IIRC), but it didn't start to bite until 64-bit Windows mattered (you could draw the line a…

X11: 1987. Still works in 2012.

X11, not backwards compatible with X10 or X9.

OpenGL 4.2, backwards compatible to OpenGL 1.0 (1992)

OpenGL ES, not backwards compatible with OpenGL.

There's an obvious parallel here of APIs being compatible within themselves but not across boundaries between major architectural revisions intended to throw out cruft and target new environments.

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

#214

Post by astrodust »

TazeTSchnitzel wrote: post #203
astrodust wrote: post #195

Earlier quoted context omitted.

That's why it's bothering a lot of people that it has "GL" in the name at all.

Why? It's basically a subset of GL, what's wrong with that? It's a bit like complaining that XHTML Basic profile is incompatible with the full XHTML.

In a fashion, OpenGL ES is about as OpenGL as C# is C.

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

#215

Post by msbarnett »

CamperBob2 wrote: post #169
MrFoof wrote: post #17

Earlier quoted context omitted.

>It has a different set of constraints. The point is to prune back the API for small devices I came here to say something along these lines, but right now I'm limited on time so I don't have time to go into specific examples. In OpenGL, there might be 5 ways to do something. Three of them are very much suboptimal, one way worked but was incredibly kludgy to write, and one was performant and pretty clean. With OpenGL…

The point is to prune back the API for small devices I don't disagree with the general sentiment that it was time to clean out the cruft in OpenGL, but I find this part of the argument to be a bit humorous. These "small, constrained devices" we're talking about are probably 10x faster than a goddamned Reality Engine. I tend to agree that the API should have been renamed entirely once it was pared down this far, as 3D…

> I don't disagree with the general sentiment that it was time to clean out the cruft in OpenGL, but I find this part of the argument to be a bit humorous. These "small, constrained devices" we're talking about are probably 10x faster than a goddamned Reality Engine.

OpenGL ES 1.0 was released in early 2003, IIRC. The decision to exclude Immediate Mode from OpenGL ES 1.0 was made sometime prior to that.

2002-2003's typical mobile hardware was pretty damn weak, in particular in the areas of CPU cycles and memory bandwidth, which is where Immediate Mode really bites you in the ass. And the RAM/ROM sizes on most of these devices were small enough that every byte you could shave off the driver was a win for application writers, so there was little desire on the part of mobile graphic hardware vendors to spend memory budget on redundant features that an application could rebuild on top of lower level primitives if they so chose.

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

#216

Post by cpeterso »

msbarnett wrote: post #213
hapless wrote: post #210

Earlier quoted context omitted.

X11: 1987. Still works in 2012.

X11, not backwards compatible with X10 or X9. OpenGL 4.2, backwards compatible to OpenGL 1.0 (1992) OpenGL ES, not backwards compatible with OpenGL. There's an obvious parallel here of APIs being compatible within themselves but not across boundaries between major architectural revisions intended to throw out cruft and target new environments.

> X11, not backwards compatible with X10 or X9.

That's why it's called X11 and not X10 ES.

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

#217

Post by fpgeek »

hapless wrote: post #210
fpgeek wrote: post #146

Earlier quoted context omitted.

You misunderstand my point about length. I'm completely aware that there are plenty of APIs that have been supported far longer than Win . That's not what I'm talking about. What I'm wondering is this: Has there ever been an API with a longer deprecation period than Win16? Remember, Microsoft announced the deprecation in 1995 (IIRC), but it didn't start to bite until 64-bit Windows mattered (you could draw the line a…

X11: 1987. Still works in 2012.

X11 wasn't deprecated in 1987, that's when it was released. So far as I know, X11 hasn't been deprecated.

Side-note: Win16 (called "the Windows API" back then) actually predates X11 (though not previous versions of X) since Windows 1.0 was released in November 1985.

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

#218

Post by fpgeek »

angersock wrote: post #137
wanderr wrote: post #126

Earlier quoted context omitted.

I'd be interested in seeing an argument explaining why these API calls smother puppies when the premise of the original article is that you can in fact offer them as an interface to the shiny new better way of doing things, without accidentally summoning cthulu. If he's wrong on that point I'd like to see a clear explanation of why.

Sure, here's my attempt at explanation: OpenGL is a gigantic mess, one which only somewhat recently has started to get better. For those that don't know, it's lineage goes back to IrisGL and big-iron Silicon Graphics machines. There's a wonderful recap of its history on Stack Overflow ( http://programmers.stackexchange.com/questions/60544/why-do-... )--long story short, design-by-committee and squabbling vendors (esp…

> It's similar to asking if people could write a portability layer atop Win32 to support Win16 to support old DOS system calls--anyone can do a subset of that and complain that "Hey, it's easy!" but to do it right (and you must do it right, or else somebody else will complain!) is very nontrivial.

Didn't Microsoft actually do that? Isn't that how we have Win16 support in 32-bit Windows 7 today?

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

#219

Post by msbarnett »

cpeterso wrote: post #216
msbarnett wrote: post #213

Earlier quoted context omitted.

X11, not backwards compatible with X10 or X9. OpenGL 4.2, backwards compatible to OpenGL 1.0 (1992) OpenGL ES, not backwards compatible with OpenGL. There's an obvious parallel here of APIs being compatible within themselves but not across boundaries between major architectural revisions intended to throw out cruft and target new environments.

> X11, not backwards compatible with X10 or X9. That's why it's called X11 and not X10 ES.

This line of reasoning is utterly absurd. They are different APIs with different names. The specifics of the substrings they have in common and the format of the substrings that differ is utterly irrelevant.

OpenCL is a different API from OpenAL, Cocos-2d is an API for an entirely different language than Cocos-2d-x, the Cocoa API is wildly incompatible with Cocoa Touch. Horrors!

You determine whether or not two APIs are compatible (or even striving to be the same kind of API) by reading the documentation, not by applying stupid heuristics to common substrings in their names.

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

#220

Post by greyfade »

hermanhermitage wrote: post #93
bcowcher wrote: post #87

Earlier quoted context omitted.

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…

Are you kidding? The 945GM doesn't have fixed-function hardware! The entire 3D pipeline save for the shaders is implemented in _software_.

Intel didn't even add fixed-function hardware until the GMA X3000 series in the G/GM965 and GL960 chipsets. Hell, it looks like they removed it in everything since the i740.

Post reply on HN