Category Archives: AIR

YouView IPTV

Having just finished working on the UI for the YouView IPTV Set Top Box, I thought I’d share some of my insights into the best practices when building applications for such resource constrained devices. The YouView UI is AIR based, written in AS3 and runs in Stagecraft 2 (AKA AIR for TV). As the name suggests, AIR for TV is a special version of the AIR runtime for embedded systems, such as Set Top Boxes. The first incarnation of the YouView UI (back when it was code-named ‘Project Canvas’) was for Stagecraft version 1, which means coding in AS2 and suffering the abysmal performance that comes with running ActionScript Virtual Machine 1.

Despite the delays and the need to code the UI from scratch in AS3, I think it was ultimately the right decision. Stagecraft 2 is a much better platform – Stagecraft 2.5.1 to be precise. It was a great opportunity to learn how to write optimal code and use hardware acceleration effectively on a resource constrained device. Regardless of which technology you’re using, here are some key things to be aware of when developing for such platforms:

  • Limit your pre-composite calculations
    In AIR/Stagecraft we’re talking about limiting display list hierarchy complexity; in HTML5 we’re talking about reducing the DOM complexity. Stagecraft (or whatever display engine you’re using) needs to traverse through the display list (or DOM), working out which areas of the screen to redraw. This is somewhat similar to how the desktop Flash Player handles redraws, but with some key differences to how it decides what needs redrawing, how it tackles moving display objects and how it delegates the work of updating the frame buffer – a subject for another time. Mostly importantly, if you’re developing for a resource constrained device (such as mobile or Set Top Box), you’ll have very limited CPU power, even if the device’s GPU (Graphics Processing Unit) affords you great hardware acceleration capabilities. So, before you can delegate any graphics compositing work to hardware, you must enumerate changes in the display list in software, right? Complex display lists are a headache for some of the low-powered CPUs found in mobiles and Set Top Boxes and this will show up as rocketing CPU usage, low framerates and few spare work cycles – AKA ‘DoPlays’ in Stagecraft. By keeping your display list shallow, with only the bare minimum of display objects on stage at any one time, you’ll be making life easier for the CPU – whether or not graphics are thereafter drawn in software or hardware.
  • Benchmark everything
    When building an application for a resource constrained device, you should be able to run each component in isolation, to assess its drain on CPU and system/video memory. There’s no point optimising the hell out of one component, when it’s actually another one that is the source of your performance bottleneck.
  • Know thine hardware acceleration capabilities
    There’s no point blindly using cacheAsBitmap and cacheAsBitmapMatrix everywhere, if it’s not going to speed things up on the target device. Worse still, too many cacheAsBitmaps and you may be just wasting valuable video memory, or causing unnecessary redraws (again, the subject of a future article). A lot of platforms will accelerate bitmaps, even if stretched, but not necessarily if flipped or rotated. Alpha on bitmaps (or anything cached as bitmap) will usually be accelerated too, but this is not necessarily the case with all colour transforms. Benchmarking any component you’re building will quickly tell you where you might have pushed it too far, but you should also have a way of verifying that a particular set of transforms is indeed hardware accelerated. Stagecraft provides this when using its –showblit command line parameter. I’ll be going into more detail about this in another post.
  • Mind your memory
    When using various hardware acceleration tricks, especially on resource constrained devices, video memory is at a premium and usually in limited supply. You will need to know the limits and have a way of seeing how much video memory your application is using at any one time – ensuring you dispose and dereference any bitmaps you’re finished with too. If your platform uses DirectFB for its rendering, as YouView does, the executable ‘dfdump’ can show you just where your video memory is going. This is something else I’ll get into in another article.
  • Blit blit blit
    This refers to blitting, where blocks of pixels are copied from one bitmap to another. This technique is used a lot in games, where graphics performance is critical, you should arm yourself with the basics of how old video games used blitting of multiple things to a single bitmap for performance and video memory efficiency.

I’ll probably go into more depth on each of these things in forthcoming posts. Stay tuned…

See also: Bitmap ‘folding’ trick

ActionScript performance tips

Here are a few simple tricks that may help the performance of your code/graphics intensive Flash movies. This is not an exhaustive list, by any means, rather some of the more effective performance tweaks to try out on your projects. There are the usual sensible coding tricks, like using local variables for oft-used references within functions, or planning your code loops carefully and breaking out of loops whenever feasible – but you should be doing these already. I’ll be adding to this post as and when I feel necessary, but will generally avoid the more granular tricks, such as bytecode optimisation. Some of those methods are too complex to explain in simple terms here and generally have a low effort-to-benefit ratio anyway:

Use scrollRect in conjunction with cacheAsBitmap. The cacheAsBitmap parameter of a movieclip can improve performance dramatically, but will cause problems if the render area of the movieclip gets too large (e.g. larger than 2880 in width or height), regardless of whether it is cropped by the viewable area of the Flash Player. The solution is to use scrollRect to constrain the rendering area to desired limits, in this example, the stage width/height:

Create bitmap snapshots of complex movieclips. Where you may have a movieclip full of layered graphical effects that isn’t animated, you can save a lot of rendering time by creating a snapshot of the movie. Similar to the cacheAsBitmap parameter, but will improve performance further if your movieclip comprises many lines or alphas. The following function shows a quick and dirty way of duplicating a movieclip as a snapshot of the original:

Use the opaque window mode trick – sparingly! Setting the wmode=opaque HTML parameter of your Flash object can improve rendering performance, but at a potential cost. Not only does it make the rendering order of movieclips and frames more ‘lazy’, but will effect keyboard interaction adversely in some browsers (especially FireFox). Use with caution.

I’ll be updating and tracking back to this post occasionally, so stay tuned…