5 ms·

A question: Why are this and the standard WebGL both based on OpenGL ES, and not OpenGL?

by maaaats 13y ago

hosay123 13y ago
ES is much more rigorously specified AFAIK, and has good mobile support.. OpenGL proper is a random extension soup.
- piranha 13y ago
  Some time ago jwz wrote an article open OpenGL ES: http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-to-the-iphone/ http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-t... He didn't like it that much.
  - masklinn 13y ago
    He didn't like it much because, amongst other things, OpenGL ES removes (completely) a number of older OpenGL features. Features which he was using in xscreensaver. If you're not porting OpenGL 1.x software (and thus not using APIs long considered deprecated/to avoid) there's no big issue with OpenGL ES as far as I know.
belandrew 13y ago
ES is a subset of OpenGL for embedded systems since it requires less die space on the hardware and is lighter on the software side as well. Anything that runs on ES should also run on standard OpenGL implementations but the reverse is not true. ES is supported on mobile phones and tablets, like Android and IOS, where people would obviously like browser support. If they used full OpenGL, they would lose out on those markets.
- masklinn 13y ago
  > Anything that runs on ES should also run on standard OpenGL implementations but the reverse is not true. Not exactly true, AFAIK, OpenGL 4.1 was the first "full" OpenGL version which was fully API-compatible with ES (2.0, you need OpenGL 4.3 for ES 3.0 API-compatibility). IIRC, none of the OpenGL versions prior to 4.1 were complete supersets of OpenGL ES.
aras_p 13y ago
Several reasons, I guess. OpenGL ES 2.0 (which WebGL 1.x is based on) is a subset of OpenGL 2.x, without a lot of legacy stuff that made sense in 1997 but not so much in 2012. In a way, using GLES2.0 is much nicer and more streamlined than "desktop GL 2.x". Also, until very recently GLES2.0 had a "conformance tests" suite to check implementations for conformance, whereas desktop GL did not. Desktop GL only got the conformance suite about right now (siggraph 2013), starting with OpenGL 4.4.
bryanlarsen 13y ago
It's my impression that OpenGL ES is basically OpenGL without a bunch of backwards compatibility crap that no modern program uses.
- btian 13y ago
  What?! Fixed function rendering pipeline continues to be fairly widely used because it's easier to develop. While I agree that modern programmable pipeline has its advantages, but backwards compatibility is crap? Why?
- zackmorris 13y ago
  OpenGL ES was a way to pass the buck to developers so companies could save money. Since the OpenGL fixed function pipeline could have been implemented to some degree above OpenGL ES (but never was), it forced developers to learn the entirety of rendering from modelview projection matrices, to setting up render buffers, to compiling shaders, and so on and so forth. The small one-page examples that made OpenGL great are now project downloads and video tutorials and blog posts full of errata and workarounds. To me, something of great value was lost in the transition, probably forever. What I see now are the great failures of OpenGL ES. Having to specify line widths in the shader. Inconsistent support for points. Not being able to predict if a shader will have one instruction too many and fall off the fast path. I've learned it to great depths but the mental pollution I had to absorb in the process has caused lasting damage in the form of resentment and exhaustion. If it was up to me, I would scrap the whole thing and just give developers full DSPs so they can write their own renderer in a language like a hybrid between Go and Matlab, but with exact specifications and basic hardware guarantees.
  - masklinn 13y ago
    > OpenGL ES was a way to pass the buck to developers so companies could save money. Since the OpenGL fixed function pipeline could have been implemented to some degree above OpenGL ES (but never was) Wasn't the fixed-function pipeline in OpenGL ES 1, and removed from 2.0 following the OpenGL 3.0 -> 3.1 transition?
btian 13y ago
Compatibility. Every device that supports OpenGL also supports OpenGL ES, but not vice versa.

A question: Why are this and the standard WebGL both based on OpenGL ES, and not OpenGL?

by maaaats 13y ago

A question: Why are this and the standard WebGL both based on OpenGL ES, and not OpenGL?

hosay123 13y ago

ES is much more rigorously specified AFAIK, and has good mobile support.. OpenGL proper is a random extension soup.

piranha 13y ago
Some time ago jwz wrote an article open OpenGL ES: http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-to-the-iphone/ http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-t... He didn't like it that much.
- masklinn 13y ago
  He didn't like it much because, amongst other things, OpenGL ES removes (completely) a number of older OpenGL features. Features which he was using in xscreensaver. If you're not porting OpenGL 1.x software (and thus not using APIs long considered deprecated/to avoid) there's no big issue with OpenGL ES as far as I know.

belandrew 13y ago

ES is a subset of OpenGL for embedded systems since it requires less die space on the hardware and is lighter on the software side as well. Anything that runs on ES should also run on standard OpenGL implementations but the reverse is not true. ES is supported on mobile phones and tablets, like Android and IOS, where people would obviously like browser support. If they used full OpenGL, they would lose out on those markets.

masklinn 13y ago
> Anything that runs on ES should also run on standard OpenGL implementations but the reverse is not true. Not exactly true, AFAIK, OpenGL 4.1 was the first "full" OpenGL version which was fully API-compatible with ES (2.0, you need OpenGL 4.3 for ES 3.0 API-compatibility). IIRC, none of the OpenGL versions prior to 4.1 were complete supersets of OpenGL ES.

aras_p 13y ago

Several reasons, I guess. OpenGL ES 2.0 (which WebGL 1.x is based on) is a subset of OpenGL 2.x, without a lot of legacy stuff that made sense in 1997 but not so much in 2012. In a way, using GLES2.0 is much nicer and more streamlined than "desktop GL 2.x". Also, until very recently GLES2.0 had a "conformance tests" suite to check implementations for conformance, whereas desktop GL did not. Desktop GL only got the conformance suite about right now (siggraph 2013), starting with OpenGL 4.4.

bryanlarsen 13y ago

It's my impression that OpenGL ES is basically OpenGL without a bunch of backwards compatibility crap that no modern program uses.

btian 13y ago
What?! Fixed function rendering pipeline continues to be fairly widely used because it's easier to develop. While I agree that modern programmable pipeline has its advantages, but backwards compatibility is crap? Why?
zackmorris 13y ago
OpenGL ES was a way to pass the buck to developers so companies could save money. Since the OpenGL fixed function pipeline could have been implemented to some degree above OpenGL ES (but never was), it forced developers to learn the entirety of rendering from modelview projection matrices, to setting up render buffers, to compiling shaders, and so on and so forth. The small one-page examples that made OpenGL great are now project downloads and video tutorials and blog posts full of errata and workarounds. To me, something of great value was lost in the transition, probably forever. What I see now are the great failures of OpenGL ES. Having to specify line widths in the shader. Inconsistent support for points. Not being able to predict if a shader will have one instruction too many and fall off the fast path. I've learned it to great depths but the mental pollution I had to absorb in the process has caused lasting damage in the form of resentment and exhaustion. If it was up to me, I would scrap the whole thing and just give developers full DSPs so they can write their own renderer in a language like a hybrid between Go and Matlab, but with exact specifications and basic hardware guarantees.
- masklinn 13y ago
  > OpenGL ES was a way to pass the buck to developers so companies could save money. Since the OpenGL fixed function pipeline could have been implemented to some degree above OpenGL ES (but never was) Wasn't the fixed-function pipeline in OpenGL ES 1, and removed from 2.0 following the OpenGL 3.0 -> 3.1 transition?

btian 13y ago

Compatibility. Every device that supports OpenGL also supports OpenGL ES, but not vice versa.