Mozilla’s WebGL2: an experimental WebGL implementation based on OpenGL ES 3.0 | Hacker News Reader

Mozilla’s WebGL2: an experimental WebGL implementation based on OpenGL ES 3.0

wiki.mozilla.org

64 pointsrobin_reala31 comments

As a new contributor to Mozilla FF, I did some work earlier this year implementing the OES_vertex_array_object. I just want to point out that it was a very open and welcoming team to work with. jgilbert was incredibly patient with me as I came up to speed on a large codebase to make this patch. I think Mozilla has a very good community and the technical review/mentorship process is top-notch. I highly recommend contributing if you are even the least bit interested.

Oh, this is exciting. I've been wondering when WebGL will switch to OpenGL ES 3.0. But is Google letting Mozilla do all the work? Are they helping with this?

I also wonder if OpenGL 4.0 will arrive sooner than expected (2014, or 2015), since with Nvidia starting to support the full OpenGL in its mobile chips, the others will be falling quite a bit behind, because I don't think it will be as easy for them to support the full OpenGL on their GPU's. Nvidia achieved it simply by using its PC architecture. None of the others have that advantage. Even Intel barely got to support OpenGL 4.0 in its PC architecture, Haswell, and they're probably years away from implementing the latest OpenGL 4.4.

"Even Intel barely got to support OpenGL 4.0 in its PC architecture, Haswell, and they're probably years away from implementing the latest OpenGL 4.4."

As memory serves, the Mesa folks usually have pretty great turnaround time on new GL feature support--and as a side effect, Intel does too.

And that's a HUGE pitty! I'm not alone when I say that this entire situation is depressing. It harms not only crossplatform success (=xTimes less money than possible, yes think about it dear Publishers).

So, do you have an idea on howto game it, to get more Hardware vendor support on Linux/Unix to become actually a "real alternative" to the DirectX competitor Microsoft? I don't believe that it's just the license, because amd/nvidia/intel give out their proprietary drivers, but we all know that they still so big time that using them is difficult.

I stand by what I think! You can downvote me another 1000 times, if you want, but that doesn't make your anonymous voice heard. Tell us instead why you think this is "so" wrong, sir?

Actually intel doesn't give out a proprietary driver, at least for new hardware (did they for old?). It's all open source in MESA now. Which is one of the big reasons that mesa has been improving so much lately, they've been pouring developers into it.

It's actually the opposite, Intel gives out their driver for old hardware, but for the recent GMA 500 they didn't yet do that. So you're 'almost' right with Intel[1], but how is that making my entire statement wrong? AMD and Nvidia and many other graphics hardware vendors don't open source their driver, but that is not the main problem. The problem is that they don't care for the Linux/Unix platform enough to make their drivers actually stable or good enough.

And yes, that's why I believe that there needs something to be done in order to get Graphics Hardware vendors do a better job with their linux drivers.

1. http://en.wikipedia.org/wiki/Graphics_hardware_and_FOSS#Inte...

The most recent released version of Mesa supports OpenGL 3.1 (which dates back to 2008 or 2009, iirc).

http://www.mesa3d.org/relnotes/9.1.5.html "Mesa 9.1 implements the OpenGL 3.1 API"

I believe I saw some recent news that 3.2 support was in the works for this fall. I'd really love to see linux intel hw gl support even hit 3.2 or 3.3 compatibility as that gets you glsl 1.5 and a bunch of improvements over 3.1. Not holding my breath for 4.x.

OpenGL 3.2/3.3 are almost finished now, the only thing missing now is GLSL 1.50 (but it's in progress).

You can see the current status here: http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt

That status document is great. Thank you!

Correction: "I also wonder if OpenGL ES 4.0 will arrive sooner than expected"

> Even Intel barely got to support OpenGL 4.0 in its PC architecture, Haswell, and they're probably years away from implementing the latest OpenGL 4.4.

Anyone serious about 3D should ignore Intel cards.

EDIT: Everyone downvoting me please provide benchmarks where Intel cards are able to beat NVidia and ATI cards in professional 3D settings.

Your comment is irrelevant and quite wrong. No one is disputing that nVidia & AMD cards (in general) have better performance, but very often Intel's offering is good enough, and people don't need more than what's enough.

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

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

Some time ago jwz wrote an article open OpenGL ES: http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-t...

He didn't like it that much.

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.

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.

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

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.

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

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?

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.

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

Ya you are right. I was startled to see I got down voted for my comment, but realized that there is quite a bit of context I skipped over. I've rewritten things for OpenGL 3 times now: once for Mac OS, once for iOS ES1 and once for iOS ES2. Then I scrapped it all and wrote some small wrappers so I could use the same code between iOS and Mac OS. We have everything defined in macros, for example MY_glGenFramebuffers() to map similar code to glGenFramebuffers() and glGenFramebuffersOES(). Unfortunately there are some iOS-specific calls that tie a render buffer's backing store to a UIView's memory so it's difficult to make a perfect wrapper. It feels like most of my day to day work now is just slogging through subtle issues with render and stencil buffers, and tweaking the shaders to even get 15 fps on older iOS devices. I get very little "actual work" done on any given day with OpenGL anymore. I don't think that it's gone the direction that it was originally intended to go. I just mean, I think OpenGL started with a scientific or mathematical approach and it's become kind of a catch-all or least common denominator for wherever the industry is going. So for example you really have to use one giant texture and one shader to do all of your work, because context switches are incredibly expensive on iOS. This doesn't make sense to me though because reading from a different texture address should be practically a free operation. My hunch is that they left off some critical piece of hardware, maybe a memory controller, or they didn't write a very good driver, so changing textures or shaders has to move a lot of data in and out of registers. I realize this is for cell phones and the hardware really is puny, but I don't think it would have been that expensive to give the hardware/drivers just that little bit of extra power to take the burden off developers. So that's what I meant about passing the buck. It's hard to explain my reasoning for all of this so I guess I came across as trollish.

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

Why isn't Mozilla working with standard bodies on this and instead trying to pushing their proprietary, developed in secret APIs on everyone?

Do they think they can just implement new web APIs without first discussing them with W3C and other browser vendors like Microsoft or Apple?

I think the intent is to get this standardised, and I'd assume they already are working with standards bodies on this. Mozilla are very much in favour of openness and I can't think off the top of my head anything they've actually done which is intentionally proprietary.

Mozilla was responsible for the original WebGL specification:

"WebGL grew out of the Canvas 3D experiments started by Vladimir Vukićević at Mozilla. Vukićević first demonstrated a Canvas 3D prototype in 2006. By the end of 2007, both Mozilla[6] and Opera[7] had made their own separate implementations.

In early 2009, the non-profit technology consortium Khronos Group started the WebGL Working Group, with initial participation from Apple, Google, Mozilla, Opera, and others.[4][8] Version 1.0 of the WebGL specification was released March 2011.[1] As of March 2012, the chair of the working group is Ken Russell."

Seems like it worked fine, so why not do it again?

As the article says, this is just a prototype, and will only ship in nightly builds.

To ship in a stable release, it would need to be standardized of course.

Good standards stem from real-world experience. It's best to implement something yourself (even better if there are other competing implementations), and then seek standardization.

Reply on news.ycombinator.com