Flash 10.1 gets a release date
In reaction to Steve Jobs' latest outrageous declarations, Kevin Lynch himself announced the release date of Flash 10.1 for Android devices:
"We look forward to delivering Flash Player 10.1 for Android smartphones as a public preview at Google I/O in May, and then a general release in June. From that point on, an ever increasing number and variety of powerful, Flash-enabled devices will be arriving which we hope will provide a great landscape of choice."
You can read is full post here : Moving Forward.
From what I'e heard from Adobe so far, Flash 10.1 for the desktop should be released before the Android version. Meaning we can expect Flash 10.1 desktop to be released in May...
Update: In the following Wall Street Journal interview, Shantanu Narayen - Adobe's CEO - also comments Steve Jobs declarations and says Flash 10.1 will be released June 17th (3'10):
Flash 11 drawing API will be hardware accelerated
I love catchy titles. I know nothing about the next major version of Flash and all of this is just speculations.
Anyway, as the whole HTML5 versus Flash battle is raging, it appears Flash relatively poor performances are indeed criticizable at best. Beside poor developers, the Flash Platform suffers from a very very slow software renderer. Or at least much slower than the rest of the platform. It's no secret: hardware acceleration is a key feature for the future of the Flash Player. It's even hard to believe it is not available yet!
As you must already know, Flash 10.1 will support OpenGL ES 2 on mobile devices to leverage the lack of CPU horsepower. While hardware HD video decoding will be available on the desktop too, the drawing API will only be accelerated on mobile devices.
Anyone knowing a bit about OpenGL ES knows it is a subset of OpenGL. Thus if it works with OpenGL ES, it should work with OpenGL. With this in mind, a few questions:
- Why isn't Flash 10.1 drawing API hardware accelerated on any OpenGL capable platform, including the desktop?
- How will it work?
- Will Pixel Bender be hardware accelerated?
1. Hardware Accelerated Desktop Flash Player
Let's face it: there must be an hardware accelerated desktop Flash Player in the works. As I said previously, OpenGL supports all features of OpenGL ES so this is not far fetched at all. Yet, it is neither released nor announced. Why?
My first guess is OpenGL provides with a lot of features that would make the desktop experience a lot smoother than just using what offers its little brother OpenGL ES. So at some point Adobe had to make a choice :
- release a fully hardware accelerated Flash 10.1 on both mobile and desktop platforms, with the last one being very far from what desktop hardware is actually capable to handle
- or release Flash 10.1 focusing on mobile devices and announce hardware acceleration for the desktop just after its the final release... and I'm guessing it might be a key feature of Flash 11
When I was at the French Flash User Group (TTFX - les TonTons FleXeurs) a few months ago, I spoke with Lee Brimelow and Mike Chambers about the just announced microphone raw-data access. I asked them why it was announced only for AIR 2.0 and not Flash 10.1. The answer was something about the "quality guys" making sure the feature was well suited on both the roadmap and the logic of the incoming updates. And this feature eventually made its way into the Flash Player! I think that's what is happening with hardware acceleration on the desktop.
But if you don't believe me, you don't have to take my word for it! What about Adobe's word? Cnuuja, one of the engineer working on the Flash Player, posted this very message on the Flash 10.1 Forum:
Can OpenGL 3.3/4.0 improve Flash 10.x ?
"Yes.... with a lot of work. We have spent the last year writing new code which allows OpenGLES2 to render flash content on mobile devices. Performance varies significantly from one gpu to the next, with some gpus being slower than the software renderer. What Flash does is significantly different from the 3d triangles+shaders GPUs were designed to support. Its a lot of work to make OGL/D3D usable as our renderer, but we're working on it 
-chris"
2. How will it work?
Just like in Flash 10.1 for mobile devices. But much faster thanks to OpenGL and Direct3D.
The internals of such feature is very important: developers must know and understand how it works to make the best out of it. Adobe already talked about how the drawing API is accelerated in Flash 10.1 on mobile devices:
"When a GPU renders vector graphics, it breaks them up into meshes made of small triangles before drawing them, a process called tesselating. There is a small cost to doing this, which increases as the complexity of the shape increases. To minimize performance impact, avoid morph shapes, which must be retesselated on every frame."
It's straight forward and I think it's actually the best (and only...) way to do it. Tesselation will create triangles by computing sets of vertices/indices (also called Vertex and Index Buffers) and push them to the graphics hardware. The end of the quote suggests such data is cached and should not be recomputed if no redraw occurs.
Something very important though: z-sorting. People might think hardware acceleration implies z-sorting. But it doesn't. When you know how 3D hardware and APIs work, you know it will be very tricky to make it work with something as general purpose as Flash. If Adobe wants to use the z-buffer, they will have to cut the compatibility with the software renderer. And I don't think this will happen anytime soon.
3. Hardware Accelerated Pixel Bender
Pixel Bender is already hardware accelerated pretty much everywhere except the Flash Platform. I'm not sure why. Still, it's hardware accelerated in other products of the Creative Suite so I guess that an OpenGL/Direct3D shader languages compliant intermediate represenation of Pixel Bender kernels does exist.
This said, it's just a matter of how to make it work with the very general purpose Flash Player. Considering Flash 10.1 is using tesselation, my guess is pixel shader should follow quite easily.
Apple makes its own compiler… illegal!
"3.3.1 … Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited)."
This is the very bad (sad) addition (restriction) to the iPhone developers program everyone is talking about right now. And I feel very concerned about this... and now everyone is wondering if software like the Flash-to-iPhone packager, Mono or Unity are definitely banned from the iPhone programming tool-chain.
I never talked about it before, but Aerys is working on a project targeting the iPhone and the iPad (among a lot of other platforms). And this very project is leveraged by some home-made code generation tool. Therefore, we are very scared of what this kind of restrictions might imply for our business.
But as scary as this statement might look at first, it is actually even funnier when you understand it makes any iPhone/iPad application illegal. And it gets even better because even Apple's standard tool-chain finds itself... prohibited!
The reason is very simple: Objective-C, C or C++ never "link" to any library providing the Documented iPhone APIs. Objective-C, C or C++ actually never link to anything. When compiling your code, the compiler creates an intermediary representation of your program in order to make it easier to (eventually cross-)compile it. In the case of GCC, the compiler used to build such applications, those intermediary languages are:
- the historical Register Transfer Language (RTL)
- the tree language GENERIC
- the SSA-based GIMPLE
(Source: Wikipedia - Intermediate language)
This very intermediate representation is built before the symbols resolution and before any linking is done. Thus, linking against the "Documented APIs" has always been done "through an intermediary translation or compatibility layer". And it won't change anytime soon! But, still, I wish good luck to Apple's engineers in their future work to patch GCC and make it "compliant" (sic!).
To me, it is the most obvious sign that Apple doesn't care about its developers (but I was still pretty thrilled to eventually become one of them about a few days ago...). Not because it bannishes any interesting cross-compiling software venture. And not even because any iPhone/iPad developper who knows about other platforms openness and ease of production will feel sick just by reading this kind of restrictions.
No. To me, Apple is losing it all simply because this kind of idiocy can only be written by someone who doesn't have a clue about how a computer/compiler works! Apple started building casual devices and ends up targeting casual developers. Could this be the first sign of how (so called) intuitiveness - when enforced by completely hermeticly closed devices - finally makes people... dumber? So now the real question is "What happens when your developers program EULA is written by a marketing control-freak moron?".
PS : The title of this article was desgined to attract the eye. It is my interpretation of the latest Apple's developers program EULA additions and I might be completely off or wrong. Anyway, the doubt and worry caused by this very fuzzy and unclear addition stands as a major issue for all the companies and developers targeting the iPhone and iPad platforms.
AS3 Monitor released on Google Code
I just released a small but useful piece of software on Google Code: my ActionScript 3.0 Monitor class. This little class makes it possible to watch the properties of any object directly on the stage.
It was inspired by Mr. Doob's Stats class. But my Monitor class is entirely dynamic and you can watch any property of any object.
The following simple (and useless?) code sample show how to track the (x, y) position of the mouse cursor on the stage:
package { import aerys.monitor.Monitor; import flash.display.Sprite; public class MonitorDemo extends Sprite { public function MonitorDemo() { var monitor : Monitor = new Monitor(30); monitor.watch(stage, "mouseX", 0xff0000, 1. / stage.stageWidth); monitor.watch(stage, "mouseY", 0x008800, 1. / stage.stageHeight); addChild(monitor); } } } |
And here is the result:
Here is another simple use case: tracking the (x, y, z) rotation of a 3D camera (the actual application is available on the official Aerys website):
The code is open source and available on Google Code. Comments and suggestions would be greatly appreciated!
Aerys
AerysFriends
- RT @UnknownFlasher: #minko workshop is live! Please join http://t.co/9rX1DJbGoh http://t.co/dypHmXUiZb
- RT @Minko3D: ok #minko devs are back to live coding a 3D game in 48h! live feed is here: https://t.co/nZ3BBxxYJg
- RT @Minko3D: #minko engineers are live coding a 3D mini-game in 48h! live feed here: http://t.co/V4bvtK9fuc
- RT @Minko3D: Want to learn more about #minko, shaders and effects? Vote for us for the next Stage3D online conference! http://t.co/h0trI8m3…
- @damoebius performance on what level? AS3 shaders already compare to AGAL bytecode with nicer syntax and more features than Instagal
Tags
Calendar
Archives
- February 2013
- January 2013
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- October 2011
- September 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- September 2010
- June 2010
- April 2010
- March 2010
- February 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- June 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008