
If you were involved in the OpenGL ES specification, you are an idiot - cpeterso
http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-to-the-iphone/
======
hermanhermitage
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
narrow viewpoint and not considering the wider implications.

In my experience, backwards compatible APIs and languages are what makes
development a pain going forward. This is not to say backwards compatibility
should not be provided in some form - but ejecting it from the core is a sane
decision.

Otherwise APIs and languages expand at an unfathomable rate. Imagine if every
API or language you ever used had features both added and removed over time to
make it a better language. Javascript without the bad parts for example.

An incremental only approach to design is non-design in my view.

Evolution both promotes and retires ideas.

~~~
StavrosK
I'm not knowledgeable about OpenGL at all, but how hard would it be to write a
compatibility layer so older apps continue to work? It could be released as a
third party shim.

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

~~~
mey
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)

~~~
hermanhermitage
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 device
manufacturers and low level app developers. As soon as they adopt 100%
compatability at their core or even offering an additional adapation layer
they will be taking time and effort from their focus.

In this instance any OpenGL shim is an Apple responsibility as they are the
SDK and environment provider. Apple and Videologic need to nut that one out
themselves.

As to a shim speeding up code its essentially comes down to any impedance
mismatch that may occur between an application writer and the API. This is
identical to buffered versus non buffered IO and whose responsibility is it to
filter idempotent operations.

When you look at a typical call stack. You'll see an application (potentially
caching and filtering state), calling a library shim (potentially caching and
filtering state), queuing and batching calls to a device driver (potentially
caching and filtering state), dispatching to a management layer (potentially
caching and filtering state), and so on, eventually getting to a graphics card
processor potentially caching and filtering state and finally to a pipeline or
set of functional blocks (which may have some idempotent de-duping as well).

Again how this is communicated to the developer or structured is an issue of
the platform provider.

Apple can choose to say we optimize nothing (ie add no fat, waste no extra
cycles) its up to you to dispatch minimal state changes, or we optimize a,b &
c... - don't repeat this work, but maybe add optimizations for d, e &f...
Thats something they need to document and advise on for their platform. Its
not part of most standards.

~~~
rys
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.

~~~
hermanhermitage
Long live mgl/sgl! The mention about hardware dedupe/filtering was more a hat
tip to culling sub pixel triangles and early culling of obscured primitives
that seems to happen on many chips these days :)

~~~
rys
We tip our hat right back! It happens to be pixel-perfect for us in this
context, and it's a large part of why we draw so efficiently. Oh, and I still
have a working m3D-based system that plays SGL games under DOS!

------
hesdeadjim
God what flamebait, how is this near the top of the front page?

When your primary argument that the ES designers were idiots is lack of
immediate mode, I'm sorry, you are the idiot. These are embedded systems with
highly constrained resources and that immediate mode API is _horrible_ for a
lot of reasons:

* Requires tons of driver calls.

* Stupidly hard to optimize on the driver side when you have no idea just how many vertices or other per-vertex data are to follow your call to glBegin.

* Trivial to replace with a much better, and much, much higher performing vertex representation either through vertex buffer objects or simple calls to glVertexPointer/etc.

* Teaches beginners the Wrong Way of doing things -- you won't use this API for anything beyond a toy program as the last thing you would do is load an exported mesh from Max or Maya and then iterate through every vertex.

Having learned OpenGL initially with the ES 1.1/2.0 spec, then transitioning
back to the desktop version, I couldn't believe how bloated the API had
gotten. There is a reason they want to deprecate most of it and move to a spec
that is similar to ES in its simplicity.

~~~
ecaron
> God what flamebait, how is this near the top of the front page?

Because the source is widely respected and has an amazing demonstrated grasp
of what good programming involves.

~~~
greggman
Yes but in this case he's an idiot. Try asking Carmack. Any GPU programmer
knows GL 1.x was utter crap. Good riddance.

~~~
astrodust
jwz, if you've been following him, is inherently pragmatic. He's a follower of
the philosophy that the computer, and by extension the frameworks and
languages to program it, should be subservient to the programmer. They
shouldn't tell you how to live your life or behave like a stubborn mule when,
for whatever well intentioned reason, people decided to overhaul the spec
everyone depended on.

I think his argument is that OpenGL ES should have had an "optimal" mode,
where performance is best using the newer calls, and "compatible" mode, where
if you don't care about performance and just want to port, you can get by.
This appears to be what the jwzgl layer does.

~~~
greggman
OpenGL ES is for "embedded systems" which basically means phones. That means
inefficient programming drains the battery. Sure if jwz want's to punish his
user's I guess that's his prerogative but it seems like a good decision to
provide an API that discourages bad practices.

Basically they decided to get rid of the cruft. OpenGL 1.x was designed in
1992? GPUs fundamentally changed in the mid 2000s and the decisions made for
OpenGL 1.x no longer fit.

If you want 1.1 go contribute to this project.
<http://code.google.com/p/gles2-bc/>

~~~
astrodust
The iPad graphics subsystem absolutely destroys anything around when the
OpenGL spec was released and many of these screen-savers were designed against
hardware that's unbelievably slow compared to an iPad.

He's not making a game that's going to drain the battery in ten seconds flat,
he's porting screensavers made in the late 1990s that were never heavy-duty to
start with.

~~~
msbarnett
Sure. _But OpenGL ES was not designed for the iPad_. The decision to reject
immediate mode was made in 2003, for the mobile devices of that time. And it
is used in the industry for devices much less powerful than the iPad, even
today.

It continues to be a popular choice for anything like the iPad, where there is
no legacy software based on regular OpenGL, because it is a _much_ cleaner and
much easier to implement stack, and because if you are writing new software
you should never be using all of that old deprecated cruft anyways.

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

~~~
semanticist
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?

~~~
retrogradeorbit
And lets not forget he's also unwilling to help people out by uploading his
OpenGL wrapper to github (or by extension any revision control system).

[http://www.jwz.org/blog/2012/06/i-have-ported-
xscreensaver-t...](http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-
to-the-iphone/#comment-106782)

~~~
bzbarsky
The source is available in
<http://www.jwz.org/xscreensaver/xscreensaver-5.16.tar.gz> and he mentions
that in his blog post.

How much more help are you expecting him to provide? Why would it be any more
"helpful" for him to put it in some revision control system instead of just
posting the source?

~~~
retrogradeorbit
I meant the OpenGL wrapper part, not the entire xscreensaver code base. It's
kind of hard to fork a tarball.

~~~
bzbarsky
How hard is it to untar, take the header and do whatever you want with it
(including putting it on github if you want)?

It's definitely a lower barrier to entry than requiring people to create a
github account!

Edit: the point being, that it's not just "in the tarball": it's in a specific
header file, and the blog post says which exact header file you want.

------
dkarl
I don't think xscreensaver is a good example of valuable OpenGL 1.3 code that
users want running on the iPhone. I think a person ought to have such an
example before they start calling people idiots. Not to say that porting
xscreensaver to the iPhone isn't cool, but it's only cool because it _is_
anachronistic and whimsically impractical, like playing GameBoy games in a
vintage arcade chassis in 2012.

 _There are a few things I couldn't figure out how to implement:_

This after a year of percolation and three days (plus a few hours) of intense
work by jwz. Given jwz's reputation as an insanely good programmer, I think
this says a lot. As in, there's a nontrivial amount of work to do to claim
_near-_ compatibility with OpenGL 1.3, and an undetermined amount more work to
claim true compatibility. Plus there may be more functionality from 1.4 and
1.5 to claim backwards compatibility with all of OpenGL 1.x. And all that to
grant a (deservedly) dead desktop API new life on a mobile platform. No wonder
they didn't bother.

------
forgottenpaswrd
Maybe the idiot is jwz.

There was a change in the technology that needed a change in the API. Not a
single GPU use a fixed pipeline anymore, so the API needs to change.

I see OpenGL as a testing platform that learned by trowing to the wall and
learning what sticks. Companies create extensions and if people find it useful
they became part of the language, but in any API there is a need for removing
what is not used anymore or can be done much more efficient with new ways.

Maintaining code takes a lot of resources and is a pain in the ass to program,
I can tell you(you have to emulate a lot of things that do not exist anymore,
including BUGS or HACKS).

I could understand not being Apple extreme here, e.g look at the Apple TV and
you only see new digital ports, but the other extreme, don't touch anything
for 20 years because it works is equally non sense..

I remember a brand new computer that was hanged 5 seconds on the start up by a
1.4M floppy disk because the people who assembled the computer were afraid to
remove the thing. I had to remove the thing, left a horrible hole and I
discovered the machine had the floppy check hardwired in the BIOS!!!

You buy a computer today and it has parallel, serial and PS2 ports with an
outdated BIOS with 1981 timings they can't change so they don't "break legacy
standards".

You buy a computer in 2012 with a 1900x1080 pixels and the first thing you see
is a horrible black screen with fuzzy letters.

Non sense. openGL needs to be way more clean that what it is now, where it is
impossible to remove anything because some company of the consortium find the
feature "essential" because they have some legacy code they are too lazy to
update.

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

------
quux
:) Back in 2008 I helped JWZ port daliclock to the iPhone and once that was
working I proposed a port of xscreensaver. He couldn't imagine ever wanting
screensavers on an iPhone at the time. Guess he changed his mind.

I also was the one that opened his eyes to the differences between OpenGL and
OpenGL ES it seems. I apologize.

~~~
SeanLuke
re: your username. Like retired basketball jerseys, shouldn't "quux" be
reserved for Guy Steele?

~~~
quux
Hmm, I didn't know the he uses quux too. I claim independent discovery.

~~~
SeanLuke
Sure that's fair enough, but still, it's a bit like using Woz as a username...

------
hoodoof
Ruthless dropping of backward compatibility is a good thing in certain
circumstances. I'm not saying this blog post is one of those cases, but for
example Microsoft Windows pays a huge price in complexity, cruft, bloat and
performance to obsessively maintain backward compatibility. Python 3 has
dropped backward compatibility and experiencing significant pain for the
decision but after getting to Python 3 it looks arguably like a better,
cleaner, more consistent language.

~~~
lucian303
Amen!

------
Ralith
The thing that particularly bothers me about this post:

> People defend this decision by saying that they "had" to do it, because the
> fixed function pipeline is terribly inefficient on modern GPUs or some such
> nonsense. These people don't know what they're talking about, because the
> contour of the API has absolutely fuck-all to do with what goes over the
> wire.

As far as I can tell from what he's written, all he's done is forcibly enact
the same inefficiencies that the paradigm shift away from immediate-mode
rendering was intended to eliminate. The contour of the API in this case has a
_great deal_ to do with what goes over the wire: most critically, correctly-
designed OpenGL ES programs will not retransmit static geometry to the GPU
every single frame.

~~~
koide
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.

~~~
Ralith
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_.

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

------
qdog
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 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. "

~~~
Ralith
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.

~~~
zokier
OpenGL > 3.1 does not require implementation of compatibility profile, which
includes deprecated funtionality. OSX doesn't.

~~~
Ralith
Awesome! I wasn't aware that had become optional.

------
opminion
This rant should probably say "my iPhone could run a full OpenGL
implementation, and instead I'm provided a subset. I proved that it could run
full OpenGL by writing most of the missing parts".

"(OpenGL ES) is a subset of the OpenGL" according to
<http://en.wikipedia.org/wiki/OpenGL_ES>

~~~
Ralith
Was there ever any question over whether an iPhone could run a full OpenGL
implementation?

Perhaps the people JWZ should be complaining about are those who decided to
provide OpenGL ES instead of OpenGL proper on the iPhone in the first place.

------
nikic
I don't know much about OpenGL ES in particular, but backwards compatibility
arguments are very tricky in general.

On the one hand you have all the people maintaining legacy apps and not
interested in improving their code. They'll scream at you for breaking BC. On
the other hand you have other people complaining that the library sucks due to
all the old stuff and why they don't just remove all the crap.

I noticed this in particularly in the context of PHP. People really hate some
parts of the language (for good!) and commonly demand a big BC breaking
release that fixes all the bad parts. But every time something _is_ fixed
(obviously breaking BC in some way) there is a big outcry about wtf the
developers have been thinking and whether they are all braindead - well, the
usual stuff.

So really, before you start calling people idiots because they didn't keep
comparability with an older version (or here even a completely different
version), think again. There probably was a lot thought put into the decision.
It's not like people just say "Oh, let's drop this, just so everyone can
change his code!"

------
AshleysBrain
My understanding is OpenGL ES is intentionally designed to be a subset of
OpenGL so mobile devices can be simpler and therefore cheaper. It shouldn't be
surprising mobile hardware and software is more limited. If deleting 80% of
the platform features made your iPhone $50 cheaper and last another hour on
battery, surely that's worth it?

Also, I believe the reason glVertex was removed is because it is a very
inefficient way to draw. It wastes a lot of CPU time in "jump in to glVertex
function, do a tiny amount of work, jump out of function, jump in to glVertex
function, do a tiny amount of work...". It's to the extent that glDrawArrays
is _always_ faster. Take a buffer, fill it with data as fast as memory can
transfer it, then a _single_ function call to send all the data in one go,
resulting in negligable overhead. Interesting anecdote: at least in my work in
2D games, modern GPUs are so fast they can render a quad faster than you can
write its vertices to a vertex buffer on the CPU. So performance is limited by
the CPU overhead! So this really makes a huge difference to the performance of
some applications. And on mobile performance is usually more of an issue. So
by removing the old functions, you're forced to do it in a more efficient way
which may boost your framerate. Not so bad, huh? Unless, of course, you write
a compatibility layer on top, which will reverse the performance gains.

Another reason there isn't a compatibility layer is it isn't OpenGL's job:
it's supposed to be a super thin layer on the hardware so you can interface to
the capabilities of the hardware as efficiently as possible. I also expect
writing a compatibility layer that is standards-compliant in the general case
is extremely difficult - check out all the effort that went in to ANGLE, for
example.

So I think it's just a misunderstanding of the purpose and design of the
tools. In future, I guess porting from OpenGL ES to desktop OpenGL would be a
lot easier. 0.02

~~~
mwd_
Part of the story here is that OpenGL ES isn't a new version of OpenGL, it's a
different API for different platforms. It's nice if you can take old code and
make it run on a mobile device easily but overall that's probably a small
consideration compared to having an clean API that performs well.

If we want to focus on immediate mode specifically, it arguably shouldn't be
used even in regular old OpenGL. It's slower and results in overly verbose
code. Most people seem to use immediate mode because that's what most of the
tutorial examples use.

Maybe one way to tackle the switch from immediate mode -> vertex arrays (and
maybe quads -> triangles) is just to make some macros that take old code
blocks and generate new ones.

~~~
AshleysBrain
Are you sure it's fair to call it a different API? OpenGL ES is officially
described as "well-defined subsets of desktop OpenGL" [1], which would suggest
it has a great deal in common with desktop OpenGL.

[1] <http://www.khronos.org/opengles/>

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

~~~
orangecat
I wasn't. I can understand getting rid of immediate mode; as jwz demonstrated
it's not that hard to rewrite glBegin/glVertex code to use vertex buffers. But
2.0 has an absurdly steep learning curve if this tutorial is accurate:
[http://developer.android.com/resources/tutorials/opengl/open...](http://developer.android.com/resources/tutorials/opengl/opengl-
es20.html). Multiple custom shaders to draw a single triangle, really?

~~~
TazeTSchnitzel
The first hurdle is a little steep, yes. You need a shader to project your
points, and a shader to texture your triangles.

But once you have those, it can scale to far more triangles.

Thing is without shaders it's still fixed-function, wich is bad.

------
exDM69
disclaimer: I write OpenGL ES implementations for living. I occasionally deal
with some of the guys writing (parts of) the GL specs.

This article is a load of bollocks. It actually isn't the first article I read
that complains about the removal of immediate mode in GLES. This article, like
the others I've read, leaves me with the impression that the author is rather
clueless.

The article essentially complains that a feature from a 20 year old API should
have been included in an API designed 10 years ago. The glBegin/glEnd API is a
horrible mistake from the start and it should have never existed. It's a good
thing it's removed from the GLES API. OpenGL 1.x and GLES 1.x are both
deprecated, more than 10 years old and should not be used any more. In any
case, he's complaining about mistakes(?) made more than 10 years ago.

One major flaw in jwz's reasoning is that something was removed. Immediate
mode was indeed removed from the spec but an implementation of GLES w/
immediate mode never existed. It was dropped from the spec to avoid having the
GLES implementers to waste time adding a legacy drawing API that is
essentially useless and has awful performance.

GLES1 was a stripped down API for early mobile 3d applications that used
rather primitive hardware or software.

There are lots of flaws in the GL(ES) API, but removal of immediate wasn't one
of them. If anything, they should have fixed/broken the API more and
intentionally destroy backward compatibility.

The the committees designing the API's are understaffed and have too much work
on their hands. They're trying to make the interests of hardware
manufacturers, content creators and OEM's match. Because of all these
pressures, they're not really doing a great API but at least we have some kind
of well-specified standard. Calling these people idiots doesn't help anyone.

With modern 3d API's, the vertex data is pushed into buffers in video memory.
If you're writing 3d code in the 21st century, that's what you should do.

So a legacy feature that the author depended on was removed and rather than
updating his code to run on modern software and hardware he re-implements it
in software. He spends 3 days doing it, gets pissed off and writes a blog
post.

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

~~~
astrodust
If you were porting GL-based screensavers that were written a decade ago you'd
probably be feeling the same way. You don't want to rewrite code that already
works on an earlier version of the spec.

~~~
TazeTSchnitzel
What earlier version? GL ES is NOT GL.

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

~~~
TazeTSchnitzel
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.

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

------
jiggy2011
Next Week: JWZ tries to port xscreensaver to webgl.

------
Bjartr
Wasn't the whole point of the reduced API surface area in ES so that
implementors only had to write the code that actually interfaces to the
graphics hardware and let higher level libraries and engines deal with
abstracting it appropriately for the task at hand?

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

~~~
fpgeek
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.

~~~
CrazedGeek
It actually has 128MB or 256MB of RAM:
<http://en.wikipedia.org/wiki/IPod_Touch#Models>

------
K2h
<As with all things, the first 90% took the first 90% of the time, and then
the second 90% took the second 90% of the time.

That math is totally consistent with my experience.

------
willvarfar
JWZ is so right.

The whole "FFP is slow" argument is completely wrong.

Most graphics drivers are broken and inefficient. Its just a lack of decent
dedicated programming effort coupled with over-management at NVidia etc.

My own brush with Khronos group back when this was being done still makes me
shudder.

[http://williamedwardscoder.tumblr.com/post/14011115100/openg...](http://williamedwardscoder.tumblr.com/post/14011115100/opengles-
i-want-my-gl-quads-back)

~~~
TazeTSchnitzel
Yeah, graphics drivers are broken and inefficient, and one reason is they have
to implement ALL of the LEGACY, DEPRECATED SPEC in SOFTWARE, because some
people's code could break.

------
Anm
Stealing this quote:

"As with all things, the first 90% took the first 90% of the time, and then
the second 90% took the second 90% of the time."

~~~
roel_v
Sorry to be _that guy_ , but that quote is over 25 years old -
<http://en.wikipedia.org/wiki/Ninety-ninety_rule> .

------
paines
This all makes me wonder, is it hindering to learn open gl even if you want to
develeop prmarily for android/iphone. On one hand I would say: Yes it is
hindering. On the other hand, it feels like a good idea to learn open gl, in
order to now how and what a rendering pipeline is, gl state machine, etc. What
do you guys think ?

------
leothekim
"I wrote this because you are all idiots."

Speaking as an idiot, why do I want to run a screensaver on my iPhone?

~~~
TazeTSchnitzel
You don't, especially an ancient one written for a deprecated graphics API
optimised for SGI Graphics workstations.

------
ajuc
JavaScript is also not "backward" compatible with Java, and their names are
similiar.

------
Groxx
So, what happens when all this less efficient drawing code now drains the
batteries of devices more quickly?

Good effort and all, and it's pretty cool that you _can_ do this, but why all
this work to avoid improving something?

------
sriram_malhar
Speaking of idiocy, a screen saver for the iphone? Jeez!! What a waste of
talent and battery.

I do agree with the sentiment that APIs should be deprecated over time.

------
rhizome
I bet people would have less of a problem with it if had been called "OpenGL
SE" instead.

------
dbbolton
All I have to say about this post is "Thank goodness for Readable."

------
rachelbythebay
One committee, ten years. One jwz, three days.

This is the stuff "10X" is made of.

~~~
Ralith
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_.

~~~
nvoorhies
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.

------
immy
jwz, how about porting the ~Aaron extension to Mac OS X now. Too bad SGI isn't
around to hold a funeral like Apple did for OS 9 :)

------
fatjokes
I'm home sick right now with a mild headache and dizziness. I thought it
wouldn't hurt to browse hacker news for a bit. Then that black/green color
scheme hit me.

------
angersock
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 causes harm to
the ozone layer, kittens, and infants. I'm pretty sure that glBegin() gave a
coworker cancer, and the matrix stack has claimed more lives than Kevorkian.

Building a shim to port over old OpenGL 1.3 apps is kind of like translating
the Necronomicon into English--possible, of questionable utility, and likely
to bring about insanity and demons.

As others have pointed out, OpenGL ES is not intended to be an extension of
OpenGL--it was a chance to break out a lot of the dumb cruft that had
accumulated into the API. Most of the features he's complaining about are
either bad practice or should be gotten rid of entirely.

Compare the length of the API listings for GL 1.x, 2.x, and modern 3.x / 4.x.
Remember that the whole thing is a hissing, clanking state machine, and that
interactions between functions can be arcane--and threading presents
additional issues.

Immediate mode rendering with glBegin()/glEnd()/glVertex()/glNormal/etc. is
ugly. Any shim that collects that information still has non-trivial work
stuffing it into a buffer, and the overhead of drawing anything with more than
a few hundred triangles soon becomes absurd. Worse, this style of programming
discourages storing geometry on the card, and that causes additional
inefficiency--and trying to use those calls remotely over X causes all kinds
of stupid as glx can barely do indirect rendering anyways.

Additionally, we have additional vertex stream attributes available now which
are very flexible and don't map onto that anymore. It's time to let go.

~

tl,dr: jwz is complaining about a fork of an API that removed cruft people
depended on, but the cruft needed removing. :(

~~~
fpgeek
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.

~~~
saurik
Right, but again: those are the parts of the API that are already discouraged
and downright deprecated as of OpenGL 2.0. If you were developing an app
targeting OpenGL 2.0, following what I understand are the best practices for
that version of the specification, OpenGL ES will require little to no
porting.

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.

~~~
fpgeek
OpenGL 2.0 was released in September 2004 (Wikipedia).

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...](http://www.khronos.org/news/press/khronos-group-
announces-the-on-time-delivery-of-the-opengl-es-1.1-specifica)

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

~~~
prodigal_erik
Seven years is not a long time. My toaster is older than that, and I like to
think the people who made that would be embarrassed if those cheap moving
parts had decayed so quickly.

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.

~~~
msbarnett
If bread had changed as much as GPUs have in the past seven years, your
toaster would be obsolete, too.

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.

~~~
gaius
Cars are switching from petrol to hybrid to electric motors, but roads still
work... "Rapidly developing" is a red herring.

~~~
tinco
Roads still work because they are too expensive to replace. GPU's and bread
are not, so your argument does not make sense.

~~~
gaius
Expensive things are more likely to work? I can tell you've not worked long in
this industry, my friend.

~~~
Symmetry
I think that paraphrase was slightly closer to the opposite of what tinco said
than what he did say.

------
haxe
Wow ... this guy is just an arrogant idiot ...

You first need to understand that opengl specification are not made to be easy
to use, but efficient. And the api design is highly constraint by the
hardware. You also need to understand that opengl 1.3 is FCKING 11 YEARS OLD !

Back in the day you had immediate mode. You first call glBegin, then make one
call to glVertex for each vertex and finally call glEnd. So if you want to
render one frame of a cube, that's 1+6*4+1=26 calls, and for each call your
cpu send data to the graphic card. There are two huge problems with that : you
need to the transfer the same vertex data to the graphic card for each frame
and your cpu processing power limit your graphic card processing power
(because cpu calls take way more time than your graphic card takes to render a
vertex).

Why was it designed like that in the first place if it's inefficient ? Easy :
there were no graphic card. All the 3D rendering was done by the cpu.

So with the development of more powerful graphic card, they updated the
specification. With the new api you allocate memory buffers of vertex directly
on your graphic card memory and you just need to call one function to render
the whole buffer. So you don't need to transfer all the vertex data at each
frame, and you don't need to do gazillion of function calls to render a cube.
THIS WAS IN 2004 !

So when the khronos consortium (just a reminder, the "idiots" are : Apple,
AMD/ATI, Nvidia, Intel, Google, Id Software, ...) decided in 2007 to make a
mobile version (ES stand for embedded system) of opengl, did they choose to
base their api on something conceived in 1992 and dropped in 2004 ? OF COURSE
NOT !

But why not keep it compatible ? Well it's a waste of time. Developers
shouldn't use deprecated functionality since 2004 in 2012, especially when
it's highly inefficient.

This guy need to grow up, understand that opengl ES main objective is not
screensavers, understand that he sometimes need to update a little bit his
programming knowledge and acknowledge that he's not an expert in the very
complex field of gpu.

tldr; he's the idiot

~~~
gaius
_Easy : there were no graphic card. All the 3D rendering was done by the cpu._

Err, what? SGI, who wrote the OpenGL spec, had rendering hardware before
OpenGL existed...

~~~
haxe
Yeah you're right, they were graphic cards, my bad, I made a shortcut. But at
the time (1992), opengl implementations were mostly on the cpu (except for SGI
graphic cards that were reserved to professionals). And the graphic card
processing power was not enough to make the cpu a bottleneck.

------
recoiledsnake
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>

~~~
Ralith
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.

------
mtgx
Speaking of which, is OpenGL ES 3.0 supposed to launch this year?

------
lucian303
A spec that's not backwards compatible. Oh my! I've never seen that before.
Get over it. Some software isn't backwards compatible. OpenGL ES != OpenGL.
Get over it.

------
gcb
someone send that post to the gnome lists... hopefully they will be using xfce
and hence be able to read it. Then just hope they get the analogy

------
VoiceOfWisdom
If you use green text on a black background you are an idiot.

~~~
tzs
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.

~~~
tptacek
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.

~~~
marshray
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.

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

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

