EDIT: 'continuing to call it "OpenGL"' -> 'using "OpenGL" in the name at all' Effectively, he's complaining about a form of false advertising.

It's incredibly daft to argue that part of a name amounts to a promise of backwards compatibility with a different API, in perpetuity. The X11 protocol isn't backwards compatible with that of X9 simply because they both share a name-fragment.

The problem then, arguably, is not that OpenGL ES is called OpenGL but that OpenGL 2.0 added an entirely unrelated pipeline to that used in OpenGL 1.3: you could then claim "how dare they reuse the name for what is now two APIs stuck into one library". However, they shared a lot of underlying conventions, and they were honest about bumping the major version number.

If anything, the fact that jwz is happy he proved--that you can build an OpenGL 1.3 emulation library over OpenGL ES--would argue to me to /not/ include the 1.x features as part of the standard, but to instead encourage third parties to distribute such libraries. The fixed function pipeline wasn't removed from the API as it is unimplementable, but because it is a ton of obsolete code that 2.x coders avoid anyway.

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.

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!

Both nVidia and ATI have committed to supporting these older APIs for the foreseeable future.

Also: old code isn't necessary un-useful code.

It was for the better of the industry. Boo-hoo. If it took him 3 days then hes a smart fucker. As someone with plenty of OpenGL AND OpenGL ES experience, I'd say it would have taken him just has much time to port his existing code.

Getting modern GPU performance, or anything close to it, through the crufty old immediate-mode API code is like drawing blood from a stone. Eventually developers need to take some responsibility for the code they're maintaining and migrate to a more modern API. Even on the desktop they'll have to do this - when their customers ask for modern GPU features, they'll have to move to OpenGL 3, which doesn't have immediate-mode either.

I think jwz's point is that he prefers having his old code run very slow through a compatibility layer rather than having to port the same not-so-important old code over the new APIs.

He wants to trade developer time for execution time, something that may be very sensible in some cases (probably not in most, but for fancy screensavers...).

If that's what you want, just write it yourself once (which he did) or use one of the many (subsets of) fixed-function pipelines running on OpenGL ES that others have made. The official 'Programming OpenGL ES 2.0' book even shows you how to do most of it, with example code included.

What jwz fails to recognize is that OpenGL ES does not only have to run on iPads, iPhones or other relatively high-powered mobile devices, but also on extremely low-powered devices with really small memory sizes (RAM and ROM) where every byte (code or data) counts. Compared to mobile devices at the time the first OpenGL ES API's were designed, an iPad could almost be considered a supercomputer. For OpenGL ES, small API size was one of the design constraints, simple as that.

Last but not least, OpenGL ES was supposed to become the industry standard for mobile 3D graphics, which means it needed strong industry support. Stuffing the API with loads of crap that almost nobody would use would drive up implementation costs for no good reason. Programmable shaders are called 'programmable' for a reason, if you want to do very specific stuff with them (such as emulating the fixed-function OpenGL pipeline), there is nothing preventing you to do so.

The single point I can kind of agree with is that maybe they should not have used 'OpenGL' in the name of the API, because it suggest at least some form of compatibility with previous OpenGL versions. Confusing indeed, but not really worth the kind of rant in this article.

OpenGL ES 1.1 (which jwz complains about here) was ratified and publicly released in August 2004 (going back to OpenGL ES 1.0 would only make the comparison worse, of course): http://www.khronos.org/news/press/khronos-group-announces-th...

That's a quite, um, impressive deprecation cycle, I suppose.

You probably have enough horsepower at your disposal to emulate each and every computer you ever bought (simultaneously!) and run all that software forever. But instead we're going to require any tool you want to use to be rewritten half a dozen times over the course of your career alone. And why? Because fuck you, we just can't be bothered to start taking engineering seriously.

This isn't about good engineering vs bad, this is about mature technology vs a rapidly developing field. Different characteristics beget different engineering trade offs.

Car engines and transmissions are the heart of the vehicle, and those change frequently as well. Roads are a fundamental, static, landscape feature today. They're like telephone poles and fiber conduits, neither of which have changed much in recent times.

Software APIs change to match the features/needs of the users and developers. Part of this is based on the changing hardware, part on desired features. The hardware today is vastly different than when OpenGL 1.1/1.5 was available so why should we be constrained to use it in the same fashion?

In short, APIs shouldn't be static for now and forever, we'd only be limiting ourselves and ignoring the fact that sometimes things change and sometimes early decisions were wrong (or less effective than desired).

Yes, and this is what makes this a bad analogy.

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.

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 offers a path to leverage 3d acceleration on these platforms that cannot be beaten in software. Sure its not as exciting as 3d with programmable shaders, but it is still useful 3d none the less.

OpenGL ES 1.1 on JavaScript would be a joke. Do you really think JavaScript is up to tens of thousands of

   glVertex
   glColor
   glNormal

The rest of the graphics world left OpenGL 1.x long ago. OpenGL 4.0 has none of the fixed function stuff in it anymore either.

Using fixed function features in 2012 is like using oldskool 80s BASIC with line numbers and no functions as your programming language.

It's time to move on.

(Not OpenGL ES1.1 but a similar narrow API. One frame latency penalty in my case as the calls enter a staging area for analysis one frame before tiling and dispatch).

Dont forget the original iPhone also has been fully sandboxed OpenGL ES1.x

So its already been done.

Things like PCC (NaCl) and Xax (to a lesser degree) also reveal surprising results as you would know.

OpenGL ES 1.1 does not have support for immediate mode, thus no glBegin/glEnd and no glVertex etc. It's just VBO:s.

Do note that fixed function does not mean same as immediate mode (which is what the glVertex etc calls are all about).

At that point, the issue is more likely to be driver quality. Allowing people to use weird fixed-function corner cases of the OpenGL spec would make problems more likely.

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.

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.

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

So, I feel my original statement was accurate in both its letter and spirit.

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?

Sure win{16,32} support a GUI with bells and whistles but that's because it evolved several years later specifically to support this newer mode of UI. It does not support 50-year old teletypes.

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 at some server versions, Vista, or, as I do, at Windows 7). No matter how you slice it, that's a long time.

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.

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

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.

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.

Which it absolutely doesn't mean you should wait 14 years to stop writing for Win16!

And I think that's what the rant is implying

Also the old OpenGL API had immediate mode functions which encouraged people to trickle in interleaved data and operations; the exact opposite of what 3D APIs need to run fast.

Imagine that you plan to manage 3Million vertex and to draw 6M points on the screen(fragments) so you make your pipes for it.

Now , what happens when you need to update only 200 pixels but want to draw 30 Million vertex on them? You can't do it on fixed.

What happens when you want to do 10 passes to the screen(60M points) but you just use textures with 4-8 vertex?. You can't do it on fixed.

With non fixed you could just use your compute units where you need them.

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 (especially the CAD folks, whom I until recently counted myself among) resulted in bloated, sad, crufty APIs.

Having to maintain a codebase to mimic old OpenGL functionality, especially when in some cases it wasn't particularly well-defined/standardized, in addition to coming up with a small profile for new features on embedded systems, would present a nontrivial burden on the driver and hardware writers. Hell, even Intel has only somewhat gotten it right recently--and they've had the OS community via Mesa do most of the work for them (as I understand it)!

These aren't features that are hugely important, these aren't features that are game changing, these are a lot of things that simply obsolete or unnecessary. jwz laments the lack of quads support, so let's start there:

OpenGL 1.x supported the following primitive types: points, lines, line strips, line loops, triangles, triangles strips, triangle fans, quads. quad strips, polygons (see http://www.opentk.com/doc/chapter/2/opengl/geometry/primitiv... for examples). Several of these options are quite redundant, and supporting them is not really helpful. Moreover, several of them present interesting questions for a driver writer: what is the preferred way of decomposing quads or polygons? Strips? Fans? Discrete triangles again?

Sphere mapping has, I believe, been replaced with cube mapping. OpenGL ES 1.1 has cube mapping as an extension, but I don't know if Apple decided to implement it or not--such is part of the evil of OpenGL, this use of extensions.

1D texturing (and 3D texturing) were omitted, again presumably to make implementors' lives easier. To face this, fill a whole 2D texture with a gradient, and clamp on the edges when sampling (glTexEnvi I think should do this...?). Hopefully that would work. Only recently have 1D and 3D textures gotten really useful, for clever tricks in passing LUTs and such to the programmable shader pipeline; I think the older use for them was ghetto cel-shading and palette mapping--cool but not critical.

~

Anyways, the problem with requiring that the library writers support all that is again that they would have to create most of the OpenGL environment (which is terrible), and then map it onto their new environment (even more terrible), as well as develop the new environment. This is nuts.

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.

For a more timely example, consider the issues folks have had getting people to move on to Python 3--and contrast that with what the Rubyists have accomplished by just moving fast and fixing things as they break.

Or think about the amount of time/money spent on keeping the COBOL infrastructure up, or supporting legacy VB6 installations.

Honestly, sometimes we should applaud vendors for Doing the Right Thing and trying to force users into fixing outdated code.

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

But the guys who wrote it weren't idiots. They were in fact super smart engineers working at the cutting edge company of the day, SGI. And they made a philosophical call, which was that OpenGL should be an abstraction of geometry and an idealized rendering pipeline with just enough hardware-specific hackery in it to make it perform[1]. They did the best they could operating under the constraints of the state-of-the-art of the time and the resources they had available. And people still use OpenGL, decades later, and have done amazing things with it.

Isaac Newton said "If I have seen further, it is by standing on the shoulders of giants". Kids these days, talking about legacy technologies, would be wise to remember that.

[1] Whereas Microsoft believed in an abstraction of physical hardware, with just enough geometry in to make it useful.

Its just that modern GPUs work in completely different ways, so this kind of API is useless for them.

If we released some sort of libc for embedded systems, specifying only fprintf(), your analogy would be valid.

  a conforming freestanding implementation is only required
  to provide certain library facilities: those in <float.h>,
  <limits.h>, <stdarg.h>, and <stddef.h>; since AMD1, also
  those in <iso646.h>; since C99, also those in <stdbool.h>
  and <stdint.h>; and since C11, also those in <stdalign.h>
  and <stdnoreturn.h>

So yes, a conforming (freestanding) C implementation without printf for embedded systems can exist.