Thanks for all the in-depth insights. As most of the time it appears easier at first glance than it actually is.
On Mon, Jul 21, 2014 at 10:22 PM, Richard Bair <richard.b...@oracle.com> wrote: > I was interested in Angle for exactly this same reason — it would allow us to > expose OpenGL at the public API level. However there are licensing issues > we’d have to look at, performance tests to be run, security audits performed, > and whether or not it is actually able to perform well. > > Although the browsers use it for WebGL, WebGL is not the main thing browsers > do. What I mean by that, is that if WebGL isn’t working, an HTML author can > detect that and redirect or provide some kind of error to the user. If GL > doesn’t work for us, we’d be dead in the water (probably just crash) without > having some kind of fallback. We could maybe just fallback to software > rendering (and realize that in such cases the performance will not be good > and people will be mad). It didn’t look like a slam dunk to me. Rather, it > seemed to me that we should allow the OpenGL stack to run on Windows with an > option, let developers opt into it, but note that it isn’t a supported > configuration so we don’t have support costs associated with it if it doesn’t > work. And we’d have to forbid it on WebStart / Applets (within reason) so as > not to allow bugs in the native drivers to be exploitable through us (if the > board causes the VM to crash, there is potentially some security issues > there). And then expose an API that works with GL, supported on Mac / Linux, > but “known to work” on Windows in cases where Windows GL support works. That > seemed to me a shorter path to victory. This sounds like there are concrete plans for this, which wood be great news. The approach where an integration API would only work on Windows with GL support would at least in our area not be uncommon. There are a number of digital media pro applications that require GL to be installed on Windows to work. Keep up the good work.
