5 ms·
More info at: http://www.adobe.com/devnet/flashplayer/articles/premium-features.html http://www.adobe.com/devnet/flashplayer/articles/premium-fea... Specifical
by chanon 14y ago
More info at:
http://www.adobe.com/devnet/flashplayer/articles/premium-features.html http://www.adobe.com/devnet/flashplayer/articles/premium-fea...
Specifically:
Premium features licensing will only be needed when both of the following APIs are used in the same application run in Flash Player:
* ApplicationDomain.domainMemory, which provides access to domain memory
* Stage3D.request3DContext, if using hardware acceleration
--
From the article, it looks like ApplicationDomain.domainMemory is required when using the Alchemy compiler which allows compiling and running C/C++ code in Flash Player. (Hmmm.. seems like a competitor to Google's NaCl)
While Stage3D.request3DContext is required for using Stage3D which enables hardware acceleration in Flash Player. Angry Birds on Facebook already uses this.
Most games coded natively in Flash/AS3 won't require both. However, I'm not sure whether Unity's export to Flash and Unreal's export to Flash require Alchemy.
In any case, the revenue share is only required when both features are used. However, again the media aren't communicating the whole deal and again it's Adobe's fault for coming up with such weird/complex terms.
Edit:
After some quick research, it seems both Unity and Unreal's export to Flash Player feature require both Alchemy and Stage3D to work. So it looks like what Adobe are trying to do here is to generate some revenue from their 'platform' as otherwise they wouldn't receive a dime from all those Unity devs who would have easily exported their project to run on Flash Player which has a ton more penetration than Unity Web Player.
I think it is unfortunate though that they chose a 'revenue share' model.
It would have been a lot better for the end developers if Adobe just charged Unity and Epic a licensing fee for targeting Flash Player.
- user2459 14y agoPerhaps Unity and Epic declined the offer.
- corysama 14y agoWell, shit... Alchemy+Stage3D is directly a competitor to NaCl+WebGL. By refusing to help NaCl become open-standards-worthy, Mozilla is going to end up watching Alchemy beat out NaCl (and Emscriptem) with a completely proprietary, revenue-shared (and therefore implicitly licensor-dependent) alternative.
- azakai 14y ago> Well, shit... Alchemy+Stage3D is directly a competitor to NaCl+WebGL. First of all, NaCl has little to do with WebGL. NaCl has it's own, non-web-standard way (like NaCl itself) to render 3D graphics. If you use NaCl, you likely do not use WebGL. > By refusing to help NaCl become open-standards-worthy, Mozilla is going to end up watching Alchemy beat out NaCl (and Emscriptem) with a completely proprietary, revenue-shared (and therefore implicitly licensor-dependent) alternative. Mozilla can't help NaCl become a relevant standard for the web, even if it wanted to. NaCl is still CPU-specific, still too complex and evolving to standardize and create alternate implementations of, and still will not be supported by browsers without plugins like the iOS browser and Windows 8 Metro. Alchemy might beat out NaCl. It works in far more places than NaCl, but it's slower, so that will be interesting to watch. But I very much doubt Alchemy will beat 3D gaming on the open web. It isn't just Emscripten, it's also Mandreel and several other C++ to JS compilers in the industry. That approach reaches more people than even Alchemy, and it reaches them with 0 license fees.
- corysama 14y agoOK, technically OpenGLES2 is the open-standard that the open-web-standard WebGL is based on. Still a big step in the right direction compared to Stage3D. Moving from ES2 to a C++ interface to WebGL would not be a huge pain at this point if someone pushed for it. That's how Mozilla /can/ help NaCl become a relevant standard for the web. It's still evolving rapidly! That could be a good thing because it's far too complex and cpu-specific /now/. With Moz's participation, that evolution could be directed to something standardizable. It's a lot of work, but it's better than sitting back and watching Adobe take over without asking for anyone's support. Right now, Alchemy runs at 40% of native speed. They are targeting 80% at public launch. We'll see how that goes... Meanwhile, I've dug deep into the performance of JS and I've been happy when I can get deeply-optimized JS to reach 10% speed compared to deeply-optimized native.
- azakai 14y agoMozilla can't make NaCl non-CPU specific. It's CPU specific by design. PNaCl, which tries to be portable, is a completely separate project (although the underlying SFI is similar), and it's too early to evaluate the performance there to see if it's worth it. So there is nothing Mozilla or Opera or anyone can do. Deeply optimized JS should run much faster than 10x slower than native. Most benchmarks I've run on compiled code are 2x-6x slower than native. And that is before JS engines actually optimize specifically for that type of code, which is happening this year.