Improving the work flow in the development of Flash applications is something that has been in my mind for some time now, specially after seeing some presentations on the subject at Max Barcelona.
Usually the applications are not big, and are developed by a single programmer in less than a month, so they are manageable, but when a big one come along chaos is installed.
This question popup up today while playing around with AIR and transparent windows. I wrote a simple actionscript app inside flex builder, that draws some sprites (that move randomly) onto a transparent AIR window.
The first time I ran the app (with only one circle), I was surprised to see my Pentium 4 (3.2 ghz) reach 30% of cpu usage to animate that single sprite. It the window had the transparency turned off the cpu usage would be 0-1%.
The second time I ran the app (with 10 circles), the frame-rate dropped dramatically from 24 to 12-fps, and the cpu usage went up to 50%. At this moment I truly believed that what I wanted to do could not be accomplished. I mean, with only 10 sprites moving around the screen all I get are 12-fps...
Having the AIR runtime installed on my mac (powerPC 1.5 ghz) I tried running the app with the 10 circles to have a laugh at the poor performance. When I saw the app running my jaw dropped... My mac was running the AIR app with the transparent window and the 10 sprites moving around at 24-fps. How could this be... I know for a _fact_ that the flash performance is ALOT worse on my mac than on the PC., so how could the mac be behaving so well... It it because macosx uses the gpu to render the windows? And because AIR is using one of those windows it's being rendered by the gpu instead of the cpu?
I decided to google for a while and found out that Windows uses layered windows to display transparent windows and that AIR is using that. I also read that when using layered windows the drawing of the windows goes into an off-screen buffer (probably inside the graphics card)
So I decided to draw 100 sprites inside the AIR app. Guess what happened? The frame-rate was still at 12-fps and the cpu was still at 50% the same values I got when drawing 10 sprites. At this moment I thought that maybe the frame-rate was so low because I have a very old graphics card.
I used another PC with a similar cpu (Pentium 4 3.4ghz) but with a kick-ass graphical card. The result: 70-fps and 15% cpu usage.
My guess is that because AIR is using transparent windows, the OS is rendering it inside the graphics card (remember the off-screen buffer) instead of the cpu.
Can anyone confirm this?
update: After a short discussion with ivan, I reckon that all flash "stuff" is still done in the flash player and is _not_ hardware accelerated. However, the transparency calculations, are done in the graphics card. If you have a good graphics card you don't need to overload the cpu with those calculations and you can use it for the flash calculations.
If you create an Actionscript Project inside Flex Buider 3 beta, there is no option to create and AIR application. However, when you create a Flex Project the option is there.
So how can you create an AIR Application in an Actionscript Project with Flex Builder 3 beta?
HLS color scheme can be awful to work with bitmapData, today we discover that motion tracking mechanisms can be improved using HLS, so there's a class for converting RBG to HLS and vice-versa.
Inside the Papervision3D source, besides existing an AS2 and AS3 version, there are five derivate branches: MaterialsRestructor, Phunky, ascollada, frustrum and timk_frustum. I decided to research a bit about each one and write about what I founded..
The most important of these branches is the one called Phunky. It is the branch that will soon became the 2.0 version of Papervision3D, which in the SVN trunk is now tagged Beta 1.7 (dated 20.08.07). So, if you're using trunk, you should expect only bug-fixes. It's a bit different from other open-source projects where trunk normally means the latest revision of the project. For Papervision3D, you can think of trunk as a stable version (whatever that means for a software that's in Beta).
Someone said on the list that "switching from trunk to Phunky shouldn't break anything (doesn't impinge on the API) but should net you a performance increase".
MaterialsRestructor was a branch created to test code regarding Materials. Once changes are tested the most likely is that they go into trunk or Phunky.
I don't know much about the 'ascollada' branch besides the fact that it was created by Tim Knip and that he tries to maintain it in sync with ascollada, a actionscript library for parsing COLLADA files. I've tested loading some COLLADA files with Beta 1.7 and it works fine so I don't have the need to use this branch yet but Ivan is using it (the DEA class), so he might have something to add here.
The 'frustum' (definition) branch has a 'BVH mocap importer class' with a beautiful sample here, but I was unable to find the real purpose of this branch. You can check the examples folder for the sample sources.
'timk_frustum' is a branch that appeared when Tim Knip put up for testing a new FrustumCamera3D, in early August 2007. This class is now also at the 'frustum' branch.
And that's it. If you know more about this and want to share please do. Thanks.
Update: John Grden posted a comment explaining a bit more about the branches, thanks!
Essentially what i'm doing here is instructing the compiler to add a frame
with myPreloader as a factory and calling my main file from it.
Should you have any questions feel free to ask, here is the swf.
Here's a rough overview of the points discussed:
Flash in mobiles
- Full fledged player on devices is on the way.
Hardware acceleration
- It will use it but will always decay to accommodate the constraints of the machines.
- And yes we'll have GPU accelerated content where available.
Different players on different platforms
- Some third parties develop their own players, but they have to pass a 'quality' test.
Video core updates
- There are gonna have updates and on the account of h.264 support we'll have a new component
and we'll have some new goodies regarding the managing of video.
3D
- Adobe are going to provide some low level routes for the engines to take advantage of.
SOE
- Search engine optimization is coming really soon we were promised.
Ok so the second day of Flash on the Beach is over.
Today we had some really nice presentations and I actually have quite a few points to check after today, mostly related to the bitmap object, mostly due to Mario Klingemann demos.
Also Craig Swan's presentation remembered me of what i really like to do and made me want to some crazy stuff and maybe just want to collaborate with him.
The cool thing about FOTB is the community spirit, putting faces on the names you see online.
Also speaking with Richard Galvan from Adobe i learned that CS4/Flash player 10 will come out 'late' next year, that h.264 is just weeks away, that they're going to be fixing the garbage collector in the AVM2, correct the localConnection hack, improving the memory management and that C++ won't probably make it into CS4 due to security issues. Also following on Richard Galvan early presentation i learned that the kinematics engine will make it into CS4 and just to wrap it up that they Adobe team is working closely with the PV3D team to get a lot more performance out of Flash 3D.
AS2 was an anarchy language, if you need to put a movieClip visually above all the things in the stage, you can do movieClip.swapDepths(this.getNextHighestDepth()). So it works, but in reality your are swapping your movieClip with a movieClip that didn’t exist, so in AS3 you can’t do that but we have setChildIndex method. You Can do setChildIndex(numChildren-1)
Tinting a MovieClip is not a new thing, we see a lot of Web sites doing that, example: In a t-shirt selling store, you choose a shirt and then you can choose it color. But yesterday me and Pedro were talking that it could be nice to fill shapes with patterns, so it quite simple:
+ Help the community
+ Explore the Flash platform
+ Create a better world
+ Research and play
Startups
We're looking for stories about startups using Flex/Flash technology. Drop us a quick e-mail or mention it to us via our Twitter account @dreaminginflash, thanks!
