more RenderObjects • There are several different RenderObjects, depending on type of element and CSS properties • RenderObjects are organised into RenderTrees
during each animation frame • RenderObjects that are not visible are removed from the rendering tree for performance reasons • Each RenderObject has its own renderer implementation (Text, Image, Video, Canvas, etc.)
First measurement pass walks the RenderTrees to calculate and layout boxes • Layers are created according to specific rules from subtrees (Tiling, Composite, etc.) • Layers are converted to textures and transferred to the GPU for compositing
transfer to GPU • CSS3 transitions and animations only send compositing geometry updates to the GPU (layers are rasterised before animation) • Any changes to the layout or content will force rasterisation of the layer and subsequent texture transfer to the GPU
– calls to getComputedValue, – changing any layout and content-related CSS properties, – reading offset, offsetParent, etc. – if required to read status, do it before modifications, not during. Ideally, treat the DOM as write-only. http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-webkit.html
layers and sends them to the GPU on each frame draw • As a result, animating scaling and rotation using JavaScript is slow (textures are rendered and transferred on each frame) • translate and opacity are non-destructive operations
animated element • Turn on debugging borders in Chrome to check layer boundaries • Watch repaint geometry in the Timeline profiles • Avoid changing RenderLayer types
than Android, but outperforms Android when using pure GPU geometry updates • Android 2.x works better with large layers, buggy 3D implementation • Android 4 rasterizes 3D layers across CSS pixels, not device pixels