Microsoft has joined Khronos, WebGL working group(twitter.com)
twitter.com
Microsoft has joined Khronos, WebGL working group
https://twitter.com/neilt3d/status/498539402407063553
6 comments
Just like the old Apple before they got "acquired" by NeXT.
I doubt there's really a "new" Microsoft. They're just in the "Embrace" phase of their usual 3-step process.
This seems such an old fashioned outlook now. MS doesn't have, and probably will never again have, a monopoly on the browser environment; they have no choice but to be good web citizens.
It is a new Microsoft, unfortunately. They are pushing stupid HTML5 everywhere :(. Might even make Dynamics AX use it.
It's interesting to see so many people supporting webGL. Other than the "same X, but now X runs inside a browser" novelty aspect, I have yet to see any evidence that webGL does anything useful. To be fair, in this respect, it's no different from flash or javascript or any of the other technologies that people use to produce inferior replacements of native applications.
Running in a browser offers an (imperfect) security sandbox on a desktop PC, so people don't have to download and run untrusted executables. It also offers portability, and a certain amount of "copy protection".
If your application is inherently networked, it works just fine in the browser.
If your application is inherently networked, it works just fine in the browser.
The sandbox is a feature afforded by the underlying OS and CPU architecture. I didn't quite understand your point.
With regards to game distribution, I don't see any particular advantage that a browser has over something like Steam. You don't need to download multiple gigabytes either. You could design a game to stream levels/assets/etc on-demand. In any case, even with webGL, a game would need to do that.
With regards to game distribution, I don't see any particular advantage that a browser has over something like Steam. You don't need to download multiple gigabytes either. You could design a game to stream levels/assets/etc on-demand. In any case, even with webGL, a game would need to do that.
The sandbox is a feature afforded by the underlying OS and CPU architecture
Absolutely not; the sandbox of Javascript apps is entirely within the browser. The CPU architecture may theoretically prevent a userspace app from breaking into ring 0, but that's not the interesting thing; you're trying to prevent random apps from gaining access to all the tasty data in userland.
"Please do not download and run random executables" is a lesson that security people have been trying to get across for a while. Running a native game executable involves trusting it not to be malware. Running a webgl or HTML5 game does not.
(The sandboxing of webgl may be dodgy, which is a weakness here.)
Absolutely not; the sandbox of Javascript apps is entirely within the browser. The CPU architecture may theoretically prevent a userspace app from breaking into ring 0, but that's not the interesting thing; you're trying to prevent random apps from gaining access to all the tasty data in userland.
"Please do not download and run random executables" is a lesson that security people have been trying to get across for a while. Running a native game executable involves trusting it not to be malware. Running a webgl or HTML5 game does not.
(The sandboxing of webgl may be dodgy, which is a weakness here.)
>Absolutely not; the sandbox of Javascript apps is entirely within the browser. The CPU architecture may theoretically prevent a userspace app from breaking into ring 0, but that's not the interesting thing; you're trying to prevent random apps from gaining access to all the tasty data in userland.
I don't know why you felt compelled to state a categorical denial when the facts dispute it. Please read up on how security tokens work in Windows, for e.g.
http://msdn.microsoft.com/en-us/library/bb625957.aspx
> Running a native game executable involves trusting it not to be malware. Running a webgl or HTML5 game does not.
There is no difference between those two executions in modern operating systems that implement mandatory access control.
I don't know why you felt compelled to state a categorical denial when the facts dispute it. Please read up on how security tokens work in Windows, for e.g.
http://msdn.microsoft.com/en-us/library/bb625957.aspx
> Running a native game executable involves trusting it not to be malware. Running a webgl or HTML5 game does not.
There is no difference between those two executions in modern operating systems that implement mandatory access control.
The thing is, it is in your browser. A machine without an internet browser is unheard of, the internet browser is everywhere. You can't say the same for Steam.
It is convenient. What is it not understandable about that?
It is convenient. What is it not understandable about that?
>The thing is, it is in your browser.
I already excluded this part from my criticism. Please read my original comment.
>You can't say the same for Steam.
So, the solution to that is to create something like Steam, but better. Choosing an inferior technology is the opposite of a solution.
I predict that advertisers are going to overuse webGL just like flash. We're going to see webGL blockers crop up the minute it gets any kind of traction. Certainly, I am not going to subject my machine to another malware vector.
I already excluded this part from my criticism. Please read my original comment.
>You can't say the same for Steam.
So, the solution to that is to create something like Steam, but better. Choosing an inferior technology is the opposite of a solution.
I predict that advertisers are going to overuse webGL just like flash. We're going to see webGL blockers crop up the minute it gets any kind of traction. Certainly, I am not going to subject my machine to another malware vector.
Technology evolves, and if you have been paying attention to browsers they have been getting better and better, and they will keep doing it.
It has three purposes:
- potential future GUI solution to end the sad HTML5-only lock of the web;
- useful for quick dirty prototypes/samples for full OpenGL tutorials;
- generating HN karma: just find any old OpenGL sample (quality doesn't matter), convert it to WebGL, post on HN (make sure to add 'WebGL' and 'JavaScript' to title) - ka-ching!
- potential future GUI solution to end the sad HTML5-only lock of the web;
- useful for quick dirty prototypes/samples for full OpenGL tutorials;
- generating HN karma: just find any old OpenGL sample (quality doesn't matter), convert it to WebGL, post on HN (make sure to add 'WebGL' and 'JavaScript' to title) - ka-ching!
Thanks for the link, but if anything, it convinced me further that webGL continues to be an inferior alternative, in performance, resource consumption and feature parity, to existing, established 3D APIs like OpenGL/Direct3D/etc.
Also, I do think the author is joking with regards to it being 'the best tested 3D API'. The author backs up this absurd claim with some 'thousands of tests' comment. Hello? Have they never visited shadertoy? Even trivial shaders cause webGL to crash because of the poor implementation quality. I refuse to believe that a person who has had any experience shipping OpenGL ES on multiple platforms could make such a statement.
Also, I do think the author is joking with regards to it being 'the best tested 3D API'. The author backs up this absurd claim with some 'thousands of tests' comment. Hello? Have they never visited shadertoy? Even trivial shaders cause webGL to crash because of the poor implementation quality. I refuse to believe that a person who has had any experience shipping OpenGL ES on multiple platforms could make such a statement.
That's good to see. Now if they could support OpenGL on Xbox and WP / Windows RT, that could be even more useful.
Nobody wants OpenGL on XBox. If anything, we'd want a PS4/Mantle style hardware level API. In practice since the hardware is so similar between XBox and PS4, the APIs would probably be pretty similar too...
On the other hand, the use of Direct3D is a competitive advantage for them. It made ports easier with the XBox 360 and it probably still makes them easier for the XBox One.
On the other hand, the use of Direct3D is a competitive advantage for them. It made ports easier with the XBox 360 and it probably still makes them easier for the XBox One.
Would have to agree. The future of Microsoft is one development platform across Windows, Windows RT, Windows Mobile and XBox.
If as a developer I could have one codebase and target all three platforms it would be pretty compelling.
If as a developer I could have one codebase and target all three platforms it would be pretty compelling.
Except that MS is losing ground. Gaming is now spilling to other platforms and Xbox / Windows will be pushed aside with time with more competition. Developers would prefer to have a good common and open API instead of using 10 different proprietary ones.
Then where is the pressure to get opengl on the consoles? In theory right now you could write some engine that used openglES 3 and ran on Android, iOS, OSX, Windows, and Linux. Your only missing parts are the three consoles, none of which show any interest in supporting write once run everywhere.
I mean, I know why - it is because the entire console model is license deals, app store cuts, and exclusives. If you could write your games and seamlessly run them everywhere, console manufacturers lose their primary pitch to consumers. Especially since this console generation isn't amazing value hardware wise, you can build a computer as powerful as either for the same price as either.
And peripherals are an awful argument, because they are all wifi / bluetooth / usb based, nothing stops these companies from selling their accessories like the Move, Kinect, Wiimote, etc as pc peripherals with open APIs besides their complacency.
I mean, I know why - it is because the entire console model is license deals, app store cuts, and exclusives. If you could write your games and seamlessly run them everywhere, console manufacturers lose their primary pitch to consumers. Especially since this console generation isn't amazing value hardware wise, you can build a computer as powerful as either for the same price as either.
And peripherals are an awful argument, because they are all wifi / bluetooth / usb based, nothing stops these companies from selling their accessories like the Move, Kinect, Wiimote, etc as pc peripherals with open APIs besides their complacency.
> Then where is the pressure to get opengl on the consoles?
Valve is just entering consoles scene. It's too early to call that pressure, but they at least plan to disrupt it. Time will tell.
> it is because the entire console model is license deals, app store cuts, and exclusives.
Yes, that's why this sick approach needs some serious disruption. Linux gaming looks like one.
> if you could write your games and seamlessly run them everywhere, console manufacturers lose their primary pitch to consumers.
Exclusivity is a weird pitch. Real pitch of consoles should be in ease of access, usability and user friendliness.
> you can build a computer as powerful as either for the same price as either.
That's exactly what consoles should be about - plug and play. No building for those who don't want it. All of that doesn't preclude using cross platform technologies. Let console makers compete on hardware (Asus, Dell whoever) and not on locking developers into their walled garden proprietary OS and APIs.
Valve is just entering consoles scene. It's too early to call that pressure, but they at least plan to disrupt it. Time will tell.
> it is because the entire console model is license deals, app store cuts, and exclusives.
Yes, that's why this sick approach needs some serious disruption. Linux gaming looks like one.
> if you could write your games and seamlessly run them everywhere, console manufacturers lose their primary pitch to consumers.
Exclusivity is a weird pitch. Real pitch of consoles should be in ease of access, usability and user friendliness.
> you can build a computer as powerful as either for the same price as either.
That's exactly what consoles should be about - plug and play. No building for those who don't want it. All of that doesn't preclude using cross platform technologies. Let console makers compete on hardware (Asus, Dell whoever) and not on locking developers into their walled garden proprietary OS and APIs.
> Nobody wants OpenGL on XBox
You mean MS doesn't want it. MS is not everybody though. Xbox is one of the ways they can keep DirectX around in the face of potential competition as you said yourself:
> Direct3D is a competitive advantage for them
Though I'd call it an anti-competitive advantage.
You mean MS doesn't want it. MS is not everybody though. Xbox is one of the ways they can keep DirectX around in the face of potential competition as you said yourself:
> Direct3D is a competitive advantage for them
Though I'd call it an anti-competitive advantage.
> You mean MS doesn't want it. MS is not everybody though. Xbox is one of the ways they can keep DirectX around in the face of potential competition as you said yourself:
As far as I'm aware, devs aren't too keen on it. No other maor consoles are using it anyway, so the X-platform argument doesn't really apply.
As far as I'm aware, devs aren't too keen on it. No other maor consoles are using it anyway, so the X-platform argument doesn't really apply.
Overall I would say devs aren't keen on either OpenGL or DirectX 11, but between the two DX11 seems to be more well regarded. DirectX 12 looks like a good step forward, but many eyes are following Mantle[1] and Metal[2] to see if they can bring new innovations to market.
1. http://www.amd.com/en-us/innovations/software-technologies/m...
2. https://developer.apple.com/library/prerelease/ios/documenta...
1. http://www.amd.com/en-us/innovations/software-technologies/m...
2. https://developer.apple.com/library/prerelease/ios/documenta...
Neither Mantle nor Metal so far achieved any wide acceptance. If AMD can convince other GPU manufactures (like Intel, Nvidia, Qualcomm and the rest) to support Mantle this can change. I don't expect Metal to become anything beyond being Apple-only API, so it's not in any way better that MS-only Direct3D, just another walled garden example.
Also, Mantle was supposed to be open. Did AMD open it already?
Also, Mantle was supposed to be open. Did AMD open it already?
> As far as I'm aware, devs aren't too keen on it.
Because of current market lock-in on DirectX. OpenGL isn't ideal, but it's not much behind. MS however doesn't want it to become better and is scared of more competition from cross platform APIs. Not sure why though. These days lock-in with API is a very dumb method to compete.
I think Valve has a good potential to push things forward.
Because of current market lock-in on DirectX. OpenGL isn't ideal, but it's not much behind. MS however doesn't want it to become better and is scared of more competition from cross platform APIs. Not sure why though. These days lock-in with API is a very dumb method to compete.
I think Valve has a good potential to push things forward.
The same applies to other game consoles.
Regardless of FOSS myths, no console has proper OpenGL[0] support.
[0] Yes, not even the PS3.
Regardless of FOSS myths, no console has proper OpenGL[0] support.
[0] Yes, not even the PS3.
Sure, others aren't any better. So Valve has a good chance to give them all a kick. Will they succeed? I hope they will. Strong competition can force current consoles makers to support OpenGL, same as happened with WebGL and IE.
Have you ever attended a GDC or used console devkits?
Valve will have to do lots of work just to try to pull off the same quality of developer support console vendors offer.
Valve will have to do lots of work just to try to pull off the same quality of developer support console vendors offer.
>Valve will have to do lots of work just to try to pull off the same quality of developer support console vendors offer.
Let them. Improving developers' tools around OpenGL was one of their key plans in this effort. So far they look serious about it.
Let them. Improving developers' tools around OpenGL was one of their key plans in this effort. So far they look serious about it.
Or because OpenGL is a relatively high-level API, and most console game developers don't want or need a high-level API that abstracts the underlying hardware, because every PS4 in the wild has the exact same hardware, so you can write two versions of the code and support every PS4 and Xbox One in existence with better performance than if you used OpenGL to write one version of the same code for both.
Things are moving forward. Modern day consoles aren't much different form a high end PC, yet on PC somehow using OpenGL is a norm and using low level APIs isn't required. Consoles shouldn't be any different these days really.
It's not that using a low-level API isn't "required," it's that it's a lot more work -- a very prohibitive amount of work. Because on PC, you can have Nvidia cards, ATI cards, Intel on-board graphics... and of course it's not like an Nvidia Fermi-based card is the same as a Kepler-based card. What OpenGL or DirectX does is let you write to an abstraction of what the underlying graphics card does, and then every graphics card provides a driver that translates the OpenGL/DirectX calls into code that runs on that particular GPU. If you wanted to write a PC game that bypassed the API and ran like a console game, you'd have to write as many different code execution paths as there are graphics drivers available for PC. It's a logistic nightmare. And that doesn't even get into how you handle cards that haven't been released yet.
But on the console, the target is constant, and every Xbox One or every Playstation 4 is identical to every other of the same console on the market. The overhead of the OpenGL/DirectX driver reduces performance, and unlike in the PC market it's no longer solving a problem -- you can very easily support two to three consoles without resorting to abstraction layers, and new consoles only come out sometime between five and ten years, so you don't have to do a lot of churn to keep up with hardware revisions.
Valve isn't shipping consoles, they're shipping living room PCs -- with all the diversity of hardware that implies. Some Steam Boxes will use Nvidia, others Intel or ATI. Games designed to run on Steam Boxes need to support all of those. They need OpenGL. But current consoles don't, and no amount of OpenGL stumping by Valve will change that, because OpenGL solves a problem the consoles have never had.
But on the console, the target is constant, and every Xbox One or every Playstation 4 is identical to every other of the same console on the market. The overhead of the OpenGL/DirectX driver reduces performance, and unlike in the PC market it's no longer solving a problem -- you can very easily support two to three consoles without resorting to abstraction layers, and new consoles only come out sometime between five and ten years, so you don't have to do a lot of churn to keep up with hardware revisions.
Valve isn't shipping consoles, they're shipping living room PCs -- with all the diversity of hardware that implies. Some Steam Boxes will use Nvidia, others Intel or ATI. Games designed to run on Steam Boxes need to support all of those. They need OpenGL. But current consoles don't, and no amount of OpenGL stumping by Valve will change that, because OpenGL solves a problem the consoles have never had.
> But on the console, the target is constant, and every Xbox One or every Playstation 4 is identical to every other of the same console on the market.
That's exactly what should change. Such situation can exist only because of lack of competition. With increased competition the overhead of writing bare metal code to support many targets will become prohibitive on consoles as well, and console makers will be forced to support portable higher level APIs. Squeezing performance by being closer to bare hardware was more reasonable in the past, when it was too weak and extra abstraction introduced too much performance penalty. Modern day hardware should be already better in this regard. And modern OpenGL isn't introducing much overhead if used properly.
> OpenGL solves a problem the consoles have never had.
They always had that problem, except there were too few of them and the problem didn't become criticial. Increased competition will blow that problem into different proportions. Supporting 2 console APIs is possible. Supporting 10 is insane and developers should demand a portable layer in such situation.
That's exactly what should change. Such situation can exist only because of lack of competition. With increased competition the overhead of writing bare metal code to support many targets will become prohibitive on consoles as well, and console makers will be forced to support portable higher level APIs. Squeezing performance by being closer to bare hardware was more reasonable in the past, when it was too weak and extra abstraction introduced too much performance penalty. Modern day hardware should be already better in this regard. And modern OpenGL isn't introducing much overhead if used properly.
> OpenGL solves a problem the consoles have never had.
They always had that problem, except there were too few of them and the problem didn't become criticial. Increased competition will blow that problem into different proportions. Supporting 2 console APIs is possible. Supporting 10 is insane and developers should demand a portable layer in such situation.
> That's exactly what should change.
Why? For people who don't want to deal with the Xbox One/Playstation 4 monocultures, there's PC gaming. It already exists. The people who choose consoles over PC gaming choose it because it's more convenient. And that convenience derives in large part from the monoculture (or duoculture, I guess). Low-overhead bare metal programming is what enables the relatively long life of most consoles compared to PC gaming, because developers have time to learn how to get the absolute best performance out of a particular hardware configuration. It costs less money up-front in hardware costs, and it's a lot less work to figure out if a game will work on your system or not (almost no work, actually).
Why? For people who don't want to deal with the Xbox One/Playstation 4 monocultures, there's PC gaming. It already exists. The people who choose consoles over PC gaming choose it because it's more convenient. And that convenience derives in large part from the monoculture (or duoculture, I guess). Low-overhead bare metal programming is what enables the relatively long life of most consoles compared to PC gaming, because developers have time to learn how to get the absolute best performance out of a particular hardware configuration. It costs less money up-front in hardware costs, and it's a lot less work to figure out if a game will work on your system or not (almost no work, actually).
> Why?
Because dealing with many APIs is an extra effort and proprietary APIs make games harder to port to other platforms. Of course those who have unlimited resources are free to write games even in assembly for each platform, but most don't have such resources.
> And that convenience derives in large part from the monoculture
Convenience of users has nothing to do with monoculture. It has something to do with form factor and design of hardware and software interfaces. Monoculture is just a sick method to lock developers into one platform. Convenience of developers on the other hand should not be based on poor competition. That's a dangerous convenience which leads to stagnation.
> Low-overhead bare metal programming is what enables the relatively long life of most consoles compared to PC gaming
Which is a double sided issue. Longer update cycle makes development simpler but it also limits creativity by artificial technical limits. The update cycle of consoles can be reasonably more frequent.
Because dealing with many APIs is an extra effort and proprietary APIs make games harder to port to other platforms. Of course those who have unlimited resources are free to write games even in assembly for each platform, but most don't have such resources.
> And that convenience derives in large part from the monoculture
Convenience of users has nothing to do with monoculture. It has something to do with form factor and design of hardware and software interfaces. Monoculture is just a sick method to lock developers into one platform. Convenience of developers on the other hand should not be based on poor competition. That's a dangerous convenience which leads to stagnation.
> Low-overhead bare metal programming is what enables the relatively long life of most consoles compared to PC gaming
Which is a double sided issue. Longer update cycle makes development simpler but it also limits creativity by artificial technical limits. The update cycle of consoles can be reasonably more frequent.
> Because dealing with many APIs is an extra effort and proprietary APIs make games harder to port to other platforms.
Game engine middleware. No sane people should be using 3D API directly anyway, unless they are writing their own engine or learning 3D programming.
Game engine middleware. No sane people should be using 3D API directly anyway, unless they are writing their own engine or learning 3D programming.
Forget about Xbox, they could start by shipping a non-prehistoric version of OpenGL on Windows.
You mean that shitty software implementation that gets replaced about 20 minutes after installing Windows? I doubt that many people would care about it if they updated it, since literally every GPU driver overrides it with better features and performance, even on bargain basement IGPs.
So are they going to join, sabotage, and abandon WebGL like they did with OpenGL?
Microsoft is a minority here and does not have the influence to pull those shenanigans. If IE were to diverge WRT WebGL functionality then it would be the outlier and ignored.
Microsoft needed to join to have an opinion at all.
Microsoft needed to join to have an opinion at all.
Unlikely, but that would've been cool. The monopoly of HTML etc. on the web has to be stopped somehow.
The monopoly of an open standard? What's wrong with you?
Call it what you want but the end result is obvious: I cannot use anything but HTML to build a browser-based GUI. It already killed the Flash and Silverlight. It is slowly spreading the metastases into mobile and desktop as well.
> It already killed the Flash and Silverlight.
Most people consider that a good thing, considering that both of these technologies were abominations that required proprietary plugins full of security holes, that didn't even run everywhere you needed them.
Most people consider that a good thing, considering that both of these technologies were abominations that required proprietary plugins full of security holes, that didn't even run everywhere you needed them.
> both of these technologies were abominations
I'll give you that they were buggy, but Flash enabled a LOT of cool stuff to be delivered on the web that HTML still can't do. Go visit Newgrounds or Kongregate and see what people have been doing, basically unchanged, since the late 90s.
I'm not sad that it's gone, but it was pretty great at what it did.
I'll give you that they were buggy, but Flash enabled a LOT of cool stuff to be delivered on the web that HTML still can't do. Go visit Newgrounds or Kongregate and see what people have been doing, basically unchanged, since the late 90s.
I'm not sad that it's gone, but it was pretty great at what it did.
Yes, Flash has some cool functionality in it, but by not being an open standard, it also held the web back because third parties could not implement it and Adobe's development model did not scale.
While Apple refusing to embed Flash on iOS is what killed it, truth be told at that time Adobe wasn't capable of delivering a mobile version that worked well, as they lacked the resources for it, just how they lack the resources to deliver a supported and polished Linux / NPAPI version, which was dropped. The version that was bundled with Android, with all due respect, was horrible. Flash only worked well due to the Windows monopoly, but the approach eventually broke down due to mobile devices.
HTML5 may not be so evolved, but at least it works on my Android in both Chrome and Firefox, it works on my MacBook, it works on my Ubuntu Linux, it works on my Windows Phone that I keep around as a paper holder and it works on my iPad. And if portability and instant updates and everything else that makes the browser great are not that important, then you're better off going native.
While Apple refusing to embed Flash on iOS is what killed it, truth be told at that time Adobe wasn't capable of delivering a mobile version that worked well, as they lacked the resources for it, just how they lack the resources to deliver a supported and polished Linux / NPAPI version, which was dropped. The version that was bundled with Android, with all due respect, was horrible. Flash only worked well due to the Windows monopoly, but the approach eventually broke down due to mobile devices.
HTML5 may not be so evolved, but at least it works on my Android in both Chrome and Firefox, it works on my MacBook, it works on my Ubuntu Linux, it works on my Windows Phone that I keep around as a paper holder and it works on my iPad. And if portability and instant updates and everything else that makes the browser great are not that important, then you're better off going native.
>HTML5 may not be so evolved, but at least it works on my Android in both Chrome and Firefox, it works on my MacBook, it works on my Ubuntu Linux, it works on my Windows Phone that I keep around as a paper holder and it works on my iPad.
I dislike HTML5 for this reason. In the heyday of Flash you could sidestep most of the bloat of the web with a click-to-play plugin setting or by not installing the extension at all, and 99% of the sites that relied on Flash completely for navigation etc. weren't worth browsing in the first place. Now that many of the capabilities of Flash are built into the browser, you don't really have a way to avoid superfluous animations and awkward nonstandard interfaces and whatnot. Every time I have to use a Wikia wiki, my computer and I each shed a single minimalist tear.
I dislike HTML5 for this reason. In the heyday of Flash you could sidestep most of the bloat of the web with a click-to-play plugin setting or by not installing the extension at all, and 99% of the sites that relied on Flash completely for navigation etc. weren't worth browsing in the first place. Now that many of the capabilities of Flash are built into the browser, you don't really have a way to avoid superfluous animations and awkward nonstandard interfaces and whatnot. Every time I have to use a Wikia wiki, my computer and I each shed a single minimalist tear.
Absolutely agree.
If Adobe had open-sourced the Flash client (but not the authoring tools) I like to think we would be in a different space technically. Certainly I hope we wouldn't have spent the last 6 years redesigning Flash by committee. Possibly licensing concerns around codecs and other things would have blocked it anyway, but one can dream.
I just think Flash deserves respect for filling in the "online multimedia" space so well while others played catch-up. Well, they caught up.
If Adobe had open-sourced the Flash client (but not the authoring tools) I like to think we would be in a different space technically. Certainly I hope we wouldn't have spent the last 6 years redesigning Flash by committee. Possibly licensing concerns around codecs and other things would have blocked it anyway, but one can dream.
I just think Flash deserves respect for filling in the "online multimedia" space so well while others played catch-up. Well, they caught up.
I wonder if Microsoft will adopt OpenGL ES for Windows Phone (and desktop Windows), too.
They already did: http://msopentech.com/blog/2013/12/20/msopentechcontributest...
It does look like a Windows Phone in that slide: https://twitter.com/Web3DConsortium/status/49853303671188685...
Well in IE on the desktop, it uses DX to render WebGL
So do Chrome and Firefox, via ANGLE.
Only because Microsoft doesn't support OpenGL in Windows, obviously.
OpenGL is supported in Windows, through installable drivers. Recent (Vista+) versions also ship with GL1.4 support via a GL->D3D translation layer, for users whose driver vendors do not ship an actual GL driver.
The main reason ANGLE is preferred is that in general, on Windows GL drivers are dramatically inferior to D3D drivers. They are slower, less stable, and sometimes omit key features. D3D historically has a much better story for preventing shaders from hanging/crashing video drivers, and for recovering from failures that do occur (lost surfaces, driver TDR, etc) - something that GL has now in modern implementations, but didn't have consistently when WebGL was introduced.
Between the more widespread availability of good D3D drivers and the stability advantages, I suspect you might not see ANGLE vanish anytime soon - despite the fact that GL drivers for Windows keep improving.
The main reason ANGLE is preferred is that in general, on Windows GL drivers are dramatically inferior to D3D drivers. They are slower, less stable, and sometimes omit key features. D3D historically has a much better story for preventing shaders from hanging/crashing video drivers, and for recovering from failures that do occur (lost surfaces, driver TDR, etc) - something that GL has now in modern implementations, but didn't have consistently when WebGL was introduced.
Between the more widespread availability of good D3D drivers and the stability advantages, I suspect you might not see ANGLE vanish anytime soon - despite the fact that GL drivers for Windows keep improving.
This one of the many reasons why I ignore Windows Phone as a viable development platform.
Also, for old monopolist Microsoft, standards were a bane because they meant smaller players could interoperate with its software, and even sometimes influence its future via standards committees. For new underdog-in-certain-markets Microsoft, standards are a blessing because it means they can interoperate with larger players' software, and even sometimes influence its future via standards committees. I'm not sure how much that's taken hold culturally within MS, though. (And, of course, there are many places they're still not the underdog.)