It is for the reason I've mentioned before: XNA abstracts out pretty much everything. With XNA you're not programming to the metal anymore, which is unfortunately true with WebGL. The greatest concern seems to be with the way OGL handles various buffers. For example in WebGL it is possible to create bufferData stating that it's of size X and provide Y values with Y much smaller than X. What you get is a buffer full of stale data from the memory. Bad idea.
Also there's much less "stuff" you can break in XNA with lower profile levels (feature sets) which are suitable for the web. E.g. you can't write shaders for the mobile devices today for both security and perf reasons. You get a preset amount of them and that's it. Yes, it's limiting, but you can't choke GPU to death and you can't submit shader payload that's known to crash given driver.
It's all about false equivalence that author makes in his blog entry. Problems exist with pretty much every piece of advanced software. But you can add small attack vector, or a large one. They are not equal and making it seem otherwise is bogus.
JS is amazing and I love 2D canvas. But WebGL is trying to put low-level stuff in the high-level code. It's awesome in terms of performance, but is inherently fragile and may be abused easily. It seems that it's not sensible programmers MS is afraid of but malicious attackers. And it's very unlikely that WebGL won't be happily abused.
As for Carmack, he stated at various occasions that he's closely following web graphics. He's also more than knowledgeable about the issues with drivers, how they can be hit even accidentally and how (un)likely it is for hardware vendor to fix them timely.
Also aside from the security, drawing from my experience, it is extremely difficult to make semi-advanced graphics code perform well and look acceptably similar on different GPUs. This is something APIs exposed in the high-level languages (which JS I think undeniably is) should hide from the developer, not dump on him. The fact that there are two different 3D canvas contexts - webgl and experimental-webgl - doesn't really help.
> The greatest concern seems to be with the way OGL handles various buffers. For example in WebGL it is possible to create bufferData stating that it's of size X and provide Y values with Y much smaller than X. What you get is a buffer full of stale data from the memory. Bad idea.
Please at least check these things before asserting them. Assuming good will, I can see how it might be easy to assume that some things that are true in desktop opengl will be true in webgl, but both the linked blog post and the webgl spec explicitly state that all buffers are initialized upon creation, and all access calls are bounds checked. Tests of this are also part of the webgl conformance suite.
That is only partially correct. As mentioned before, there are two types of WebGL canvas contexts out there: webgl and experimental-webgl. Former does not put the GLX_ARB_create_context_robustness extension in place, which is basically what you're referring to.
> It is for the reason I've mentioned before: XNA abstracts out pretty much everything. With XNA you're not programming to the metal anymore, which is unfortunately true with WebGL.
I have not followed silverlight development for some time, but looking at their documentation, they are using shaders written in HLSL under shader model 2.0. This is roughly equivalent to GLSL ES, which is what WebGL uses. As for the graphics functionality subset for mobile: that is exactly what OpenGL ES 2 was written for (with and by the mobile hardware vendors themselves). Hence the limitations on looping, dynamic indexing, etc.
It is for the reason I've mentioned before: XNA abstracts out pretty much everything. With XNA you're not programming to the metal anymore, which is unfortunately true with WebGL. The greatest concern seems to be with the way OGL handles various buffers. For example in WebGL it is possible to create bufferData stating that it's of size X and provide Y values with Y much smaller than X. What you get is a buffer full of stale data from the memory. Bad idea.
Also there's much less "stuff" you can break in XNA with lower profile levels (feature sets) which are suitable for the web. E.g. you can't write shaders for the mobile devices today for both security and perf reasons. You get a preset amount of them and that's it. Yes, it's limiting, but you can't choke GPU to death and you can't submit shader payload that's known to crash given driver.
It's all about false equivalence that author makes in his blog entry. Problems exist with pretty much every piece of advanced software. But you can add small attack vector, or a large one. They are not equal and making it seem otherwise is bogus.
JS is amazing and I love 2D canvas. But WebGL is trying to put low-level stuff in the high-level code. It's awesome in terms of performance, but is inherently fragile and may be abused easily. It seems that it's not sensible programmers MS is afraid of but malicious attackers. And it's very unlikely that WebGL won't be happily abused.
As for Carmack, he stated at various occasions that he's closely following web graphics. He's also more than knowledgeable about the issues with drivers, how they can be hit even accidentally and how (un)likely it is for hardware vendor to fix them timely.
Also aside from the security, drawing from my experience, it is extremely difficult to make semi-advanced graphics code perform well and look acceptably similar on different GPUs. This is something APIs exposed in the high-level languages (which JS I think undeniably is) should hide from the developer, not dump on him. The fact that there are two different 3D canvas contexts - webgl and experimental-webgl - doesn't really help.