Mobile Safari rendering info

The Mobile Safari browser gets its performance boost by leveraging the GPU on the device. During animations that adjust the transform or opacity of an element, the browser basically takes snapshot of the element being animated and sends the image as a texture bitmap to the GPU for compositing. Mobile Safari enforces a 1024 pixel restriction on the width and height of this texture image. I'm not sure if this is a software or hardware limit. If the dimensions of the animated element exceeds this threshold, the browser forces that element into tile-rendering-mode. In this mode, the browser actually breaks up the image representation of the element into tiled images that are less than or equal to 512 pixels in width or height ... basically breaking up the element into multiple images that are less than 1024 pixels in both width and height. The problem with this is two fold:

• If the element representation is broken up into N tiles, the browser will render that element N times. It renders into each tile by offsetting the rendering by the tile position, within the original image, and then clipping to the dimensions of the tile, as it draws the entire element. Once again, it means the element is drawn N times.

• Tiles are not rendered until they intersect with the viewport. This means, depending on how complicated the element, or any of its children are, there may be a flash of the un-rendered tile to the screen, since the rendering is done asynchronously in software on the UI thread.

Since tiles are cached, the browser won't have to redraw the tile for subsequent steps of a given animation unless something in the element changes.

So how do you avoid this potential flashing? The only solution I've heard from folks, including the Apple developers, is to break up what you are animating into elements that result in images that are less than the 1024 pixel threshold.