5 ms·

The article puts too much blame on Unity and not enough blame on browser vendors. This is hinted at in the article: > Browsers are the programs which eat all

by azakai 11y ago

The article puts too much blame on Unity and not enough blame on browser vendors. This is hinted at in the article: > Browsers are the programs which eat all of a computer's free memory, and the half-finished Unity WebGL build often causes crashes and closes browser tabs (especially in Chrome). The main problem is that Chrome has deprecated NPAPI before it is capable of running content like Unity well. If you look at Unity's forums, you can see lots of posts talking about Chrome-specific issues, for example http://forum.unity3d.com/threads/webgl-issue-on-chrome.336871/ http://forum.unity3d.com/threads/webgl-issue-on-chrome.33687... http://forum.unity3d.com/threads/bugs-in-chrome-stuttering-and-javascript-error-on-reloading-page.337880/ http://forum.unity3d.com/threads/bugs-in-chrome-stuttering-a... As those threads say, many Unity games run well in other browsers, but since Chrome is dominant in the market (over 50%), poor Chrome performance makes Unity look bad. But this isn't Unity's fault. Chrome decided to deprecate NPAPI now, before it has a good-enough solution for running large asm.js codebases. For example, on the Massive asm.js benchmark, Chrome is well behind both Firefox and Edge, http://www.winbuzzer.com/2015/07/28/asm-js-only-benchmarking-asm-js-javascript-performance-of-microsoft-edge-vs-google-chrome-44-vs-firefox-39-xcxwbb/ http://www.winbuzzer.com/2015/07/28/asm-js-only-benchmarking...

justinschuh 11y ago
I want to be clear that I fully intend to spend my weekend with my family, and not arguing this with you. So, I'll avoid rehashing any of our past discussions regarding technical concerns with asm.js. However, as the person responsible for Chrome's NPAPI deprecation, I just want to set the record straight regarding Unity. Unity previously had a high quality NaCl port (long before asm.js ever existed) and I fully expected that they would continue to support it. Plus, long prior to NPAPI deprecation the Unity NPAPI plugin was on our security blocklist due to a rash of vulnerabilities. So, I don't know why Unity chose to drop support for NaCl, but it occurred well after they became aware of our plans to remove NPAPI. And if you want a public record, you'll notice that Unity 4.3 was released (without NaCl support) months after our NPAPI announcement: http://answers.unity3d.com/questions/574054/can-i-use-native-client-nacl-in-unity-43.html http://answers.unity3d.com/questions/574054/can-i-use-native...
- azakai 11y ago
  Not sure what I did to deserve that hostility. I respect you and your work, and I agree that deprecating NPAPI is a good thing. I don't know anything about why Unity stopped supporting NaCl. But the fact remains that Chrome has left Unity no good option. Chrome's asm.js performance on Unity (and large asm.js codebases in general) is lagging. NPAPI is gone (again, a good thing by itself). NaCl exists, but would require Unity to maintain support for a platform only for a single browser.
  - justinschuh 11y ago
    It's not hostility. It's just that you're a very passionate Mozilla employee and a very passionate creator of asm.js. And from past experience I expect that you'll be willing to continue a debate longer than I can. Plus, you already know that I have reservations about asm.js, and it's just not worth rehashing that debate (accepting that WebAssembly appears to be heading in a direction that addresses most concerns, so I should offer well earned kudos on that front). Getting back to your point, pragmatically speaking, maintaining a port is a distinction with less difference than implied. First, any reasonably complicated NPAPI plugin needs to handle a range of browser-specific quirks, meaning that significant porting is unavoidable even if it's bundled into one binary. Second, Unity supports ActiveX in IE, so they're clearly already comfortable maintaining a browser-specific port that doesn't offer any of the security or platform portability benefits of NaCl. Outside of that, there's just the one-sided nature of the argument. As a creator of asm.js you are obviously a huge proponent. However, you must appreciate that not everyone perceives it the way you do, and not everyone agrees with the path you chose for adding support into Firefox. So, the technical burdens on another browser are just not the same, and in the specific case of Unity in Chrome have to be balanced against the fact there was already a tremendous past investment in a high-quality implementation. So, no, I completely disagree with the framing that "Chrome has left Unity no good option". Independent of any work in Chrome on better supporting asm.js, the fact is that Unity had at least one other good option. So, I'm sure Unity had their reasons for the path they chose, but it was and continues to be a very explicit choice.
    - 11y ago
akira2501 11y ago
> As those threads say, many Unity games run well in other browsers, but since Chrome is dominant in the market (over 50%), poor Chrome performance makes Unity look bad. But this isn't Unity's fault. If your product runs poorly on the dominant market platform, then that _is_ your fault. Especially as Chrome provides source, a reasonable community centered around that source, and strong developer tools to allow third parties to achieve superior performance on their browser. It's understandable, but the Unity developers made a guess as to the future state of the market and that guess was wrong.
- Dantus 11y ago
  Unity's WebGL is still officially marked as being experimental, so it can't be expected to be a perfectly smooth experience. If Chrome uses more memory than other browsers, it is definitely not Unity's fault. Having access to the source code won't change anything. Chrome is behind the competitors right now when it comes to memory usage with WebGL, but that may change even in the near future.
lucss 11y ago
I agree, in the earlier days of chrome I was not a fan because of the performance it had with the flash player. Now is kinda the same story with unity... this plugin is heavy, well lets cut it. We should protect unity and stop using Chrome I say.

by azakai 11y ago

justinschuh 11y ago

I want to be clear that I fully intend to spend my weekend with my family, and not arguing this with you. So, I'll avoid rehashing any of our past discussions regarding technical concerns with asm.js. However, as the person responsible for Chrome's NPAPI deprecation, I just want to set the record straight regarding Unity. Unity previously had a high quality NaCl port (long before asm.js ever existed) and I fully expected that they would continue to support it. Plus, long prior to NPAPI deprecation the Unity NPAPI plugin was on our security blocklist due to a rash of vulnerabilities. So, I don't know why Unity chose to drop support for NaCl, but it occurred well after they became aware of our plans to remove NPAPI. And if you want a public record, you'll notice that Unity 4.3 was released (without NaCl support) months after our NPAPI announcement: http://answers.unity3d.com/questions/574054/can-i-use-native-client-nacl-in-unity-43.html http://answers.unity3d.com/questions/574054/can-i-use-native...

azakai 11y ago
Not sure what I did to deserve that hostility. I respect you and your work, and I agree that deprecating NPAPI is a good thing. I don't know anything about why Unity stopped supporting NaCl. But the fact remains that Chrome has left Unity no good option. Chrome's asm.js performance on Unity (and large asm.js codebases in general) is lagging. NPAPI is gone (again, a good thing by itself). NaCl exists, but would require Unity to maintain support for a platform only for a single browser.
- justinschuh 11y ago
  It's not hostility. It's just that you're a very passionate Mozilla employee and a very passionate creator of asm.js. And from past experience I expect that you'll be willing to continue a debate longer than I can. Plus, you already know that I have reservations about asm.js, and it's just not worth rehashing that debate (accepting that WebAssembly appears to be heading in a direction that addresses most concerns, so I should offer well earned kudos on that front). Getting back to your point, pragmatically speaking, maintaining a port is a distinction with less difference than implied. First, any reasonably complicated NPAPI plugin needs to handle a range of browser-specific quirks, meaning that significant porting is unavoidable even if it's bundled into one binary. Second, Unity supports ActiveX in IE, so they're clearly already comfortable maintaining a browser-specific port that doesn't offer any of the security or platform portability benefits of NaCl. Outside of that, there's just the one-sided nature of the argument. As a creator of asm.js you are obviously a huge proponent. However, you must appreciate that not everyone perceives it the way you do, and not everyone agrees with the path you chose for adding support into Firefox. So, the technical burdens on another browser are just not the same, and in the specific case of Unity in Chrome have to be balanced against the fact there was already a tremendous past investment in a high-quality implementation. So, no, I completely disagree with the framing that "Chrome has left Unity no good option". Independent of any work in Chrome on better supporting asm.js, the fact is that Unity had at least one other good option. So, I'm sure Unity had their reasons for the path they chose, but it was and continues to be a very explicit choice.
  - 11y ago

akira2501 11y ago

> As those threads say, many Unity games run well in other browsers, but since Chrome is dominant in the market (over 50%), poor Chrome performance makes Unity look bad. But this isn't Unity's fault. If your product runs poorly on the dominant market platform, then that _is_ your fault. Especially as Chrome provides source, a reasonable community centered around that source, and strong developer tools to allow third parties to achieve superior performance on their browser. It's understandable, but the Unity developers made a guess as to the future state of the market and that guess was wrong.

Dantus 11y ago
Unity's WebGL is still officially marked as being experimental, so it can't be expected to be a perfectly smooth experience. If Chrome uses more memory than other browsers, it is definitely not Unity's fault. Having access to the source code won't change anything. Chrome is behind the competitors right now when it comes to memory usage with WebGL, but that may change even in the near future.

lucss 11y ago

I agree, in the earlier days of chrome I was not a fan because of the performance it had with the flash player. Now is kinda the same story with unity... this plugin is heavy, well lets cut it. We should protect unity and stop using Chrome I say.