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

141–150 of 225 posts

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

#141

Post by me2i81 »

tptacek wrote: post #70
tzs wrote: post #55

Earlier quoted context omitted.

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.

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.

If I recall correctly, those green phosphors were long persistence, so they could have a lower refresh rate. Amber and white phosphors came along later when it didn't matter anymore because logic got faster. Some of the first terminals I used had core memory, so they still retained their contents when turned off.

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

#142

Post by derpmeister »

Anm wrote: post #77

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

Which is of course a thinking error, he meant: "As with all things, the first 90% took the first 90% of the time, and then the remaining 10% took the second 90% of the time.".

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

#143

Post by greggman »

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…

Fixed function is no easier to make safe than shaders so that's a false assumption.

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
calls per model per frame?

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.

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

#144

Post by greggman »

astrodust wrote: post #116
greggman wrote: post #106

Earlier quoted context omitted.

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

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 th…

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/

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

#145

Post by greggman »

StavrosK wrote: post #6
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…

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.

http://code.google.com/p/gles2-bc/

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

#146

Post by fpgeek »

derpmeister wrote: post #140
fpgeek wrote: post #110

Earlier quoted context omitted.

Oh, I completely agree with the spirit of your statement. And my disagreement over the letter is over the interpretation of an unqualified "Windows 8" (or "Windows 7"), not about the substantive facts. 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?

I think if you focus on the win{16,32} API, it doesn't do any justice to, for instance, the C library. FreeBSD has always supported binaries from various UNIX systems and I think this heritage goes back a bit further then 1995. Also, windows bundles a c library of its own which implements a significant subset. Sure win{16,32} support a GUI with bells and whistles but that's because it evolved several years later spec…

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

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

#147

Post by greggman »

kevingadd wrote: post #47
mattrobertso wrote: post #43

Earlier quoted context omitted.

I thought the issue with immediate mode which prevented its inclusion (in ES) was that immediate mode is very inefficient for the CPU, resulting in increased battery drain on smartphones and tablets.

All rendering is in some capacity incremental. Sometimes you keep that (incrementally constructed) list of vertices around, of course. If you look at the old immediate mode API, fundamentally, you're just passing in some floats that it copies into a buffer. This is not an expensive thing to do. It's not free, sure, but CPUs aren't bad at it. It's just some overhead compared to if you were to hand an entire buffer (in…

Modern GPUs have to put the vertices in vram before they can render them.

That means immediate mode emulation is effectively this

    everyframe:
      a) copy all vertices from user code to some cpu buffer
      b) at draw time, copy cpu buffer to vram
      c) ask GPU to draw
steps A and B are very expensive CPU wise as well as waste memory.

vs OpenGL ES 2.0

    init time:
       put vertices in vram

    everyframe:
       ask GPU to draw

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

#148

Post by retrogradeorbit »

bzbarsky wrote: post #119
retrogradeorbit wrote: post #100

Earlier quoted context omitted.

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

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?

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

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

#149

Post by retrogradeorbit »

cma wrote: post #109
retrogradeorbit wrote: post #100

Earlier quoted context omitted.

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

the exact same criticism applies to you. why haven't you posted it to github yet?

Cause I don't care one bit. Unlike jwz who seems to care a hell of a lot.

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

#150

Post by roel_v »

ecaron wrote: post #104
hesdeadjim wrote: post #64

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…

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

Eh, not any more. JWZ is a has-been, who admittedly did good things back in the 90's, but who has lost touch with the industry when he became a hobby coder. This post is a clear demonstration of that - if he knew even a little bit what he was talking about, he wouldn't make the outrageous claims he does. But no, he just want to hang on to his toys he wrote 15 years ago and have them work with just a recompile on platforms that don't even remotely resemble the platforms he wrote them for back then. That's just absurd. And yes, I too complain (loudly) when I have to change code to accommodate changes in the platform (like how VS12 doesn't support WinXP) but in the end, deep down, I recognize that that's just how it has to go, and so should somebody who knows (or should know) much better than me, like JWZ.
Post reply on HN