Optimizing Animations For CloudTV
Optimizing animations for CloudTV is mostly the same as for other mediums, but there are some differences. You could compare developing for CloudTV to developing for mobile devices that have limited resources. This document is intended for developers who are already familiar with optimizing animations for other devices. It only describes CloudTV specifics.
This document applies to platform version V1.6 and higher.
The most important difference lies in the way CloudTV is handling the compositing. Normally you would create compositing layers for elements that are going to be animated such that animations will benefit from hardware acceleration. CloudTV doesn't have hardware acceleration, i.e. we don't create layers that we send to the GPU. But we benefit from compositing layers as well. When we detect a compositing layer we treat it as an indivisible graphical unit that is moved and manipulated as a whole. This results in a stream of higher interface quality and/or lower bandwidth usage. The principles are more or less the same. Unfortunately on CloudTV, not creating a compositing layer has a higher visibility. The animation could look jerky and/or the bandwidth will rise.
Practically, try to minimize the paints. Again, this is important for every medium but even more important for CloudTV. You only want to have paints operations when new content becomes visible in the screen. Here is a simple example of a row with some colored circles that you could animate from left to right and visa versa.
The image shows an example of the animation after a key press of the left or right compass key. In theory only one paint operation should happen (i.e. only one circle has new content and becomes visible in the viewport). The timeline shows this behavior. To achieve this, all seven (two extra for animating in and out) circles are positioned absolutely (using the CSS transform property) and have the null transform hack applied.
Other than other mediums we don't have VRAM which could be a bottleneck if you create too many compositing layers. For best performance you can therefore create a compositing layer beforehand if you know a layer is going to be animated in the future (you could see a small delay in the animation when creating a compositing layer dynamically).
Important to note is that though we have a larger frame budget on our platform, the last two processes, compositing and mpeg encoding, which are basically for free in browsers, are the most expensive part in the CloudTV system. A full screen repaint can easily take up to 100ms to render and encode, depending on complexity of the screen. Though when encodings are cached, this cost will drop to zero. A second important note is that in CloudTV, animations are timed based on mpeg frames, and are allowed to run ahead or behind real-time for a bit. Because mpeg play out always uses a few buffers, these can catch some of those hiccups. Otherwise we skip a frame.
Here you can see all your compositing layers as black borders within the visual screen (white area with blue border). On the left you can select a particular compositing layer (which makes the compositing layer turn green) and read some internals about it, such as the reason why it is a layer. More interestingly, you could use the cursor keys left and right to see the animation per frame. Each frame has its own information on what happened and the total time to generate (which should be less than 10-15ms).