6 ms·

I can speak to WebGL as we've actually built some stuff on top of it. Yes performance is good, sometimes. But if your user is on hardware like Intel X3100 gra

I can speak to WebGL as we've actually built some stuff on top of it. Yes performance is good, sometimes. But if your user is on hardware like Intel X3100 graphics cards, then the WebGL context will run in software mode, performance will be dismal, and you as a developer don't have any real checks to see that. Secondly, hardware support for WebGL is very dismal right now. For example, newly shipping MacBook Air's don't support WebGL. Third, we found so many inconsistencies across different hardware and different browsers that it made it not worth it to work on a WebGL project for the time being, especially for a small team. We wrote a number of runtime checks, but we still could not account for all the bugs, or find ways around every one of them. If you're writing a new 2D game in HTML5 from scratch, you'll have a much larger market share by going after a slightly simpler (artistically) game using canvas, rather than trying to go for more horsepower with WebGL. However, WebGL can be useful for porting, if you'd like to see an OpenGL game you've already made come to the browser.

AshleysBrain 15y ago
Wow, a software rendered WebGL context? I hope browsers blacklist those drivers/cards, because that doesn't sound very useful at all...
- alexhaefner 15y ago
  Yeah we found really dismal support for X3100 hardware. It doesn't support the return statement in vertex or fragment shaders due to a driver bug, and it doesn't support gl_PointCoord in the fragment shader. Yet chrome and firefox would allow this hardware to open a WebGL context, with no warning that these basic features of OpenGL are not supported.
  - marshray 15y ago
    Perhaps you see why some of us are skeptical when WebGL's proponents downplay concerns about it enabling security bugs. The hardware provides a full-featured CPU with DMA access to the host's memory. Everything better go just right, or it's going to end up remotely exploitable.
    - AshleysBrain 15y ago
      I think it's unfair to call out WebGL specifically when the same is theoretically possible in Flash 11's Stage3D and Silverlight 5's Direct3D.
      - marshray 15y ago
        Fair enough, but that's not really a very good argument for its inherent security either. There is a long history of problems with Flash. Silverlight has had vulnerabilities as well. But those are 3rd party binary plugins. It's a lot easier to disable, uninstall, and move beyond 3rd party plugins than it is widely-adopted standards implemented by the browser vendors themselves. It's because it is so appealing and has the potential to become quite popular that we're talking about it now.
      - luriel 15y ago
        Just because other technologies are even worse doesn't make WebGL's security any more acceptable. John Carmack: "I agree with Microsoft’s assessment that WebGL is a severe security risk. The gfx driver culture is not the culture of security."
    - Klinky 15y ago
      The hardware provides a full-featured CPU with DMA access to the host's memory. What part of WebGL gives a programmer unrestricted access to the host's memory? Everything better go just right, or it's going to end up remotely exploitable. The same could be said for practically any program or web app. Your web browser could have a buffer overflow in it's HTML parsing engine, yet I don't hear you speaking out against HTML... - http://secunia.com/advisories/12959/ http://secunia.com/advisories/12959/
      - marshray 15y ago
        What part of WebGL gives a programmer unrestricted access to the host's memory? Ever had a video driver bug crash an application or bluescreen Windows? Your web browser could have a buffer overflow in it's HTML parsing engine, yet I don't hear you speaking out against HTML It's a fair point. Security is about trade-offs. I am indeed concerned about HTML and do most browsing in a VM. But to me WebGL is farther out on the risk/benefit spectrum than HTML. I would not accept it for ads or ordinary page content. I would consider enabling it selectively for an app that I carefully decided to trust. * Admittedly I have not tried, but I suspect it's going to be very difficult to get it to work well from within a VM. * HTML parsers and renderers have indeed had plenty of vulnerabilities. They have taken years to get as secure as they are today and we may not have seen the last of the exploitable bugs in them. * HTML parsers have been implemented from the beginning to accept untrusted data from the internet. 3D graphics drivers, on the other hand, are designed primarily for performance in a scenario where they are run by a single-user game on the local machine, often with Admin privs already. * We saw how many years it took Microsoft (the company that could reportedly turn on a dime) to 'get' security to the point that they could ship a secure browser. I don't see much evidence that graphics vendors are even thinking about it yet. * Apple knows that WebGL bugs will result in jailbroken iPhones. Guess how many years their OpenGL support level is behind the PC...on the very same GPU hardware? Last I checked, someone reported getting OpenGL 3.2 working on a Mac. I've had usable OpenGL 3.3 on a freaking Linux laptop for a couple of years now. More powerful GPUs are up at 4.2. * A buffer overflow in HTML does not automatically amount to a kernel level compromise, (some recent font handling bugs in Windows notwithstanding :-). In fact, the latest generation of sandboxed browsers are building defense in depth mitigations. Any buffer mismanagement between the GPU, driver, GL, and WebGL seems very likely to result in complete pwnage. The GPU can access host memory directly with no access permissions. Don't get me wrong - I love the idea of WebGL and want it to succeed. I just would hate to see it end up like Flash, struggling for years to retrofit security onto something that wasn't originally spec'd for it and a bunch of its users getting pwned in the process.
petercooper 15y ago
newly shipping MacBook Air's don't support WebGL. How new? My MBA is only 2 or 3 months old and WebGL runs fine (and fast) under Chrome 17. Indeed, under the test on the parent link, I get about 500 objects on Canvas, 6000+ on WebGL.
- alexhaefner 15y ago
  The latest generation wasn't working in my testing. Hmm, well as of Chrome 15/Firefox 7 they were not supported. Would you try out http://drawwith.me/demo http://drawwith.me/demo and let me know if that works?
  - kstenerud 15y ago
    Works for me. MBP bought last March when the first Sandy Bridge models were released.
  - jonmrodriguez 15y ago
    I have the Nov 2010 MacBook Air, and that demo works fine under both Firefox 7.0.1 and Chrome 15.0.874.121
  - petercooper 15y ago
    From what I can make out of it being a drawing app, yep, it works. This is a 11" MBA with 1.6GHz i5 and Intel HD Graphics 3000 384 MB. Browser is Chrome 17. OS is Lion.
- narkee 15y ago
  Wow, with my 2010 13" Macbook Pro, using Chrome 17 (canary) I get 400 using canvas, and 430 using webgl.
  - ricardobeat 15y ago
    Something wrong with Canary? Using Chrome 16, same MBP, I get 390 vs 2600
pandaman 15y ago
WebGL is disabled by default in Safari on Air (maybe other Macs too) but if you go to Preferences/Advanced and check "Show Develop menu" then you will be able to enable WebGL support through Develop menu. On my Mid-2011 Air it appears pretty fast.

AshleysBrain 15y ago

Wow, a software rendered WebGL context? I hope browsers blacklist those drivers/cards, because that doesn't sound very useful at all...

alexhaefner 15y ago
Yeah we found really dismal support for X3100 hardware. It doesn't support the return statement in vertex or fragment shaders due to a driver bug, and it doesn't support gl_PointCoord in the fragment shader. Yet chrome and firefox would allow this hardware to open a WebGL context, with no warning that these basic features of OpenGL are not supported.
- marshray 15y ago
  Perhaps you see why some of us are skeptical when WebGL's proponents downplay concerns about it enabling security bugs. The hardware provides a full-featured CPU with DMA access to the host's memory. Everything better go just right, or it's going to end up remotely exploitable.
  - AshleysBrain 15y ago
    I think it's unfair to call out WebGL specifically when the same is theoretically possible in Flash 11's Stage3D and Silverlight 5's Direct3D.
    - marshray 15y ago
      Fair enough, but that's not really a very good argument for its inherent security either. There is a long history of problems with Flash. Silverlight has had vulnerabilities as well. But those are 3rd party binary plugins. It's a lot easier to disable, uninstall, and move beyond 3rd party plugins than it is widely-adopted standards implemented by the browser vendors themselves. It's because it is so appealing and has the potential to become quite popular that we're talking about it now.
    - luriel 15y ago
      Just because other technologies are even worse doesn't make WebGL's security any more acceptable. John Carmack: "I agree with Microsoft’s assessment that WebGL is a severe security risk. The gfx driver culture is not the culture of security."
  - Klinky 15y ago
    The hardware provides a full-featured CPU with DMA access to the host's memory. What part of WebGL gives a programmer unrestricted access to the host's memory? Everything better go just right, or it's going to end up remotely exploitable. The same could be said for practically any program or web app. Your web browser could have a buffer overflow in it's HTML parsing engine, yet I don't hear you speaking out against HTML... - http://secunia.com/advisories/12959/ http://secunia.com/advisories/12959/
    - marshray 15y ago
      What part of WebGL gives a programmer unrestricted access to the host's memory? Ever had a video driver bug crash an application or bluescreen Windows? Your web browser could have a buffer overflow in it's HTML parsing engine, yet I don't hear you speaking out against HTML It's a fair point. Security is about trade-offs. I am indeed concerned about HTML and do most browsing in a VM. But to me WebGL is farther out on the risk/benefit spectrum than HTML. I would not accept it for ads or ordinary page content. I would consider enabling it selectively for an app that I carefully decided to trust. * Admittedly I have not tried, but I suspect it's going to be very difficult to get it to work well from within a VM. * HTML parsers and renderers have indeed had plenty of vulnerabilities. They have taken years to get as secure as they are today and we may not have seen the last of the exploitable bugs in them. * HTML parsers have been implemented from the beginning to accept untrusted data from the internet. 3D graphics drivers, on the other hand, are designed primarily for performance in a scenario where they are run by a single-user game on the local machine, often with Admin privs already. * We saw how many years it took Microsoft (the company that could reportedly turn on a dime) to 'get' security to the point that they could ship a secure browser. I don't see much evidence that graphics vendors are even thinking about it yet. * Apple knows that WebGL bugs will result in jailbroken iPhones. Guess how many years their OpenGL support level is behind the PC...on the very same GPU hardware? Last I checked, someone reported getting OpenGL 3.2 working on a Mac. I've had usable OpenGL 3.3 on a freaking Linux laptop for a couple of years now. More powerful GPUs are up at 4.2. * A buffer overflow in HTML does not automatically amount to a kernel level compromise, (some recent font handling bugs in Windows notwithstanding :-). In fact, the latest generation of sandboxed browsers are building defense in depth mitigations. Any buffer mismanagement between the GPU, driver, GL, and WebGL seems very likely to result in complete pwnage. The GPU can access host memory directly with no access permissions. Don't get me wrong - I love the idea of WebGL and want it to succeed. I just would hate to see it end up like Flash, struggling for years to retrofit security onto something that wasn't originally spec'd for it and a bunch of its users getting pwned in the process.

petercooper 15y ago

newly shipping MacBook Air's don't support WebGL. How new? My MBA is only 2 or 3 months old and WebGL runs fine (and fast) under Chrome 17. Indeed, under the test on the parent link, I get about 500 objects on Canvas, 6000+ on WebGL.

alexhaefner 15y ago
The latest generation wasn't working in my testing. Hmm, well as of Chrome 15/Firefox 7 they were not supported. Would you try out http://drawwith.me/demo http://drawwith.me/demo and let me know if that works?
- kstenerud 15y ago
  Works for me. MBP bought last March when the first Sandy Bridge models were released.
- jonmrodriguez 15y ago
  I have the Nov 2010 MacBook Air, and that demo works fine under both Firefox 7.0.1 and Chrome 15.0.874.121
- petercooper 15y ago
  From what I can make out of it being a drawing app, yep, it works. This is a 11" MBA with 1.6GHz i5 and Intel HD Graphics 3000 384 MB. Browser is Chrome 17. OS is Lion.
narkee 15y ago
Wow, with my 2010 13" Macbook Pro, using Chrome 17 (canary) I get 400 using canvas, and 430 using webgl.
- ricardobeat 15y ago
  Something wrong with Canary? Using Chrome 16, same MBP, I get 390 vs 2600

pandaman 15y ago

WebGL is disabled by default in Safari on Air (maybe other Macs too) but if you go to Preferences/Advanced and check "Show Develop menu" then you will be able to enable WebGL support through Develop menu. On my Mid-2011 Air it appears pretty fast.