Unlike a PC, an embedded device is often limited by the limited CPU speed, RAM, memory and is optimized for the particular application. When it comes to running Flash player on such device, often the expectations are that Flash should run 'as good as' desktop player, if not better.
As a matter of fact, Flash Lite is designed to perform much better in terms of memory footprint as well as runtime memory consumption on an identical device running Flash 8. Adobe has also simplified support for several of the computationally intensive features in Flash Lite that eases load on CPU. These include gradient and filters. Take a look at the Adobe page, and you'll realize that quite a few CPU intensive features that are not required in embedded system are not included.
The performance on the embedded devices is a function of almost entire features that make up the device. If I had to make a list, it will be as follows:
- Content
- CPU
- RAM
- OS
- Display size
- Other (device drivers, other applications running on the device etc.)
So if you are looking to port Flash player on a device, and write an application, be very careful of these factors. Minimum recommendation is 200 MHz CPU with 32 MB RM from Adobe's web site. But that doesn't mean that it'll play youtube videos for you at reasonable fps. It will vary based on the available memory. Even two devices, with identical configurations, running different OS will have different performance.
In the subsequent posts, I'll elaborate more on each of these and offer some insights how they can impact the performance.
Friday, January 18, 2008
Wednesday, January 9, 2008
Flash player as an application on top of OS
For those of you who are planning on using Flash to an embedded device, please keep in mind that Flash requires multitudes of support from OS. The device configuration (in terms of peripherals, RAM, display, input devices etc). can impact the Flash significantly. In general, just because Flash runs on a device running operating system X, doesn’t mean that it’ll run on a different device running operating system X. Depending on how different the configuration is, it may require complete rework or minor change. So just because you are migrating your
There are a few major areas where Flash requires support from OS:
Input devices: Actionscript application running on Flash can be taking input from the device, and that input needs to be mapped inside the Flash player. In general, input devices could be a keyboard, touchscreen, a panel, of switches- whatever. Each one of them, when invoked, generates an event which the OS recognizes.
From Flash point of view, each event needs to be ‘understood’ by the actionscript. For example, a content developer might write something like ‘Press y to continue’. For a PC based application, since the keyboard has a standard set of characters, ‘a’ is always represented by an ASCII value. In embedded devices though, these can be mapped to different values. For example, an ‘up’ key can be mapped to any of the buttons on the cell phone. So when developing your application, you need to be aware of this distinction.
Audio: Flash is a very powerful tool that provides vector processing, audio, video, animation and the whole range of capabilities. So in general, there are multitudes of events happening while it is playing the content. The audio is an important part of the overall Flash player sync for audio and video. You must have noticed that even though for some content, the video skips, audio continues to play normally. Internally quite a bit of work takes place that drives this mechanism. When considering an embedded system, you may want to use a generic driver that is well adapted so Flash will work without any major modification.
Video: Flash requires support from OS in terms of framebuffer when it comes to blitting the screen. In general, Flash creates the output buffer based on input actionscript content and it impacts the behavior quite a bit. This is particularly true for Linux, since the choice of UI layer- GTK/X11, GTK/directfb, DirectFB, QT etc. can have a major impact on Flash.
In short, when you choose the OS for your device, you may want to consider these factors before making any decision.
There are a few major areas where Flash requires support from OS:
Input devices: Actionscript application running on Flash can be taking input from the device, and that input needs to be mapped inside the Flash player. In general, input devices could be a keyboard, touchscreen, a panel, of switches- whatever. Each one of them, when invoked, generates an event which the OS recognizes.
From Flash point of view, each event needs to be ‘understood’ by the actionscript. For example, a content developer might write something like ‘Press y to continue’. For a PC based application, since the keyboard has a standard set of characters, ‘a’ is always represented by an ASCII value. In embedded devices though, these can be mapped to different values. For example, an ‘up’ key can be mapped to any of the buttons on the cell phone. So when developing your application, you need to be aware of this distinction.
Audio: Flash is a very powerful tool that provides vector processing, audio, video, animation and the whole range of capabilities. So in general, there are multitudes of events happening while it is playing the content. The audio is an important part of the overall Flash player sync for audio and video. You must have noticed that even though for some content, the video skips, audio continues to play normally. Internally quite a bit of work takes place that drives this mechanism. When considering an embedded system, you may want to use a generic driver that is well adapted so Flash will work without any major modification.
Video: Flash requires support from OS in terms of framebuffer when it comes to blitting the screen. In general, Flash creates the output buffer based on input actionscript content and it impacts the behavior quite a bit. This is particularly true for Linux, since the choice of UI layer- GTK/X11, GTK/directfb, DirectFB, QT etc. can have a major impact on Flash.
In short, when you choose the OS for your device, you may want to consider these factors before making any decision.
Flash player on embedded devices
OK- I’ve been wanting to start a blog for some time, but as you know, ‘inertia’ is the word when it comes to starting something new. As with the laws of physics, it always takes more effort to start something new, rather than keeping something running. Now that I have typed this far, hopefully I’ll keep writing more. In my blogs, I intend to focus on Adobe Flash, audio/video and multimedia devices in general. As you know, the company I work for, California Software Labs is Flash player distributor. In general, I have worked with Flash player 7, Flash Lite 2, 2.1 and now Flash Lite 3. The porting has been done to various OSes, such as Linux (all kinds of flavors- RedHat, Fedora, uC, BlueCat…..), Windows CE 4.250/6.0, Windows Mobile 5/6, Nucleus, ThreadX, etc. etc. The underlying CPU has been ARM (most popular) followed by X86, followed my MIPS and others. Each system had unique configuration, and really had very wide range of application- set top box, digital signage, handheld pda, cell phone, remote control, kiosk, low end laptops, mp3 players……. etc. etc. The array of applications where Flash is being used is vast, and having worked with several of them, I have developed my own set of secret weapons which I hope to share with you. If you have any questions, or need more information about Flash in the embedded world, please use the links on the blog page to contact me.
Subscribe to:
Posts (Atom)
