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?
If you were involved in the OpenGL ES specification, you are an idiot
121–130 of 225 posts
Re: If you were involved in the OpenGL ES specification, you are an idiot
#122God 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…
> These are embedded systems with highly constrained resources
Gigahertz quadcores with several gigabytes of RAM is "constrained resources" nowadays? I agree with you though - it's flamebait. But it's also true.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#123[deleted]
Re: If you were involved in the OpenGL ES specification, you are an idiot
#124I'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.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#125JWZ 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...
Re: If you were involved in the OpenGL ES specification, you are an idiot
#126I 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 cause…
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.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#127Earlier quoted context omitted.
* It costs money to document. * It costs money to implement. Three days for a lone coder, much more than that for a careful consistent development process. * It costs money to develop regression and validation tests. * It costs money to test, including collecting all the different hardware it needs to be tested on. * It costs money to fix bugs in it. * It costs money to answer questions from developers about it. * Th…
While that's all true - it completely ignores the externalities. It cost Jamie 3 or 4 attempts and eventually 3 days work to get his unbroken code running on the new OpenGL version. What's the multiplier needed to account for the cost this change incurred for all the other developers who wrote code using OpenGL before ES? Sure, maintaining backwards compatibility is costly for a project like OpenGL. But if you choose…
[deleted]
Re: If you were involved in the OpenGL ES specification, you are an idiot
#128Earlier quoted context omitted.
" … but to instead encourage third parties to distribute such libraries." 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 th…
It's not something that can be done in 3 days. Fixed function on top of shaders is a PITA. If you want any kind of speed you've got to generate shaders on the fly based on which features you've turned on or off. Otherwise you create an uber shaders that's show as shit. 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 functio…
Finally someone actually works in the cg industry replies. +1 to this. No one really uses fixed function stuff these days, everything is shaders and vertex and index buffers. There are no fixed function hardware units, everything in the graphics pipeline is programmable and done in shaders. Even using fixed function stuff on today's hardware forces the driver to compile a built in shader. In the interest of keeping driver size small (for mobile apps), they force the programmers to write their own shaders and throw away the fixed function stuff that would bloat the driver and slow the shader compiler.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#129Earlier quoted context omitted.
Now that smartphones and tablets have respectable GPUs in them, is there any reason why they shouldn't implement the full OpenGL spec?
> Now that smartphones and tablets have respectable GPUs in them, is there any reason why they shouldn't implement the full OpenGL spec? To what benefit? OpenGL ES is basically OpenGL minus all of the bits you really really should have stopped using over a decade ago. Originally all of that crap was culled out because it was only realistic to write new software for such resource constrained devices anyways, so why bu…
Afaik OpenGL ES 2.0 is only a subset of OpenGL 2.0, and doesn't have anything from latter versions (3.x and 4.x). Fixed-function pipeline was removed in OpenGL 3.1 (core). See eg OSX implementation of OpenGL.
So OpenGL ES is not OpenGL minus legacy bits. It was that back in the day, but today it is far smaller subset. Implementing OpenGL > 3.0 would not require implementing fixed-function pipeline, and would benefit programmers using the latest and greatest features.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#130People 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.
OpenGL > 3.1 does not require implementation of compatibility profile, which includes deprecated funtionality. OSX doesn't.