1. Rendering Optimizations A few insights on how to cope with high quality, rich webapps Apr. 2013 Arthur Jamain arthur@joshfire.com

2. CONTEXT Whats going on and where ?

3. CONTEXT TECHNOLOGIES Rich HTML5/JS Applications expected to behave like a native app. Basic access to native features Low resources, high-end display Joshre

4. CONTEXT OBJECTIVES High expectations of UX quality Heavy content : lengthy videos or images lists, overall rich UIs Animations and multidirectional nested scrolling Cost effectiveness. Joshre

5. CONTEXT VALIDITY Most of the concepts described in this presentation are heavily platform dependent Rendering engines do implement the same specifications but in different forms, and future evolutions may invalidate this document. The current (early 2013) implementations of iOS, Android, BB10, Microsoft... devices' default web engines all fit this document Joshre

6. WEBAPPS General Considerations

7. WEBAPPS RUNTIME A Native Webview runs the HTML5 App Alongside are plugins : camera, sensors, etc. The Webview is entirely opaque to the native runtime o No (native) memory handling / garbage collection o No pre-rendering / dynamic loading / caching of table cells, list views or scroll views o Sparse critical error handling Joshre

8. WEBAPPS RENDERING The one Webview's engine renders the whole app o We're talking UI here, it is fairly easy to defer big calculations to native components. Its size in memory and its resource consumption are "unitary" It can use the device's processor, RAM and GPU to achieve its rendering process Decreasing the Webviews (hence, the app) resource consumption can only be done by altering the JS / CSS / HTML code which determines what is rendered and how. Joshre

9. PAGE RENDERING In the kingdom of the blind

10. RENDERING WHAT IS IT ? The process of JS HTML load, parse transforming the document into what we see on our CSS Alter DOM Tree screen. Input : DOM (nodes, CSS) Output : Bitmaps to be Render Tree & Render Layer Tree drawn on the browsers' Rendered Bitmap canvas Joshre

11. RENDERING THE RENDER TREE Ordered tree of visual elements (renderers) representing the DOM elements Enables painting the contents in their correct order DOM Nodes spawn one or more renderers under certain conditions only : display mode, visibility... Their ordering depends on their box-model settings, sizing rules, etc. Controlling the size and depth of the render tree allows control of the rendering performances Joshre

12. RENDERING THE RENDER TREE Check these options in Chrome&Co. to visualize the content rectangles Each renderer has children renderers Each renderer draws a rectangle defined by its computed CSS properties and its childrens ones. Joshre

13. RENDERING LAYERS ! The browser then draws a grid of rectangles. Controlled-size layers hence keeping several smaller objects in memory The renderer's rectangles are split among these "master" layers/rectangles These rectangles are then printed as bitmaps on the screen, asynchronously. Note : These layers or tiles are drawn by the GPU Joshre Html content that spans on the whole page. Note that the grey element is split and drawn among 4 tiles

14. Stop ! Recap time.

15. RECAP DOM Tree Initially, and whenever the drawing loop ticks :! o The DOM nodes that have changed spawn Render Tree and modify renderers accordingly, creating or completing the rendering tree! o Renderers calculate their respective Render Layer Tree (Grid and layers) rectangles and their contents! o These rectangles are projected onto cells of GPU a grid! o Each cell of the grid is drawn as a bitmap on the screen by the GPU Joshre

16. RENDERING OPTIMIZATIONS HACK AROUND

17. OPTIM HARDWARE ACCELERATION Tiling may produce weird visual effects o They are drawn on a single thread, asynchronously. o Heavier tiles may be drawn visually significantly after lighter tiles To avoid this, we grant large elements their own "master" layers ! This is what "accelerating" an element refers to. Joshre The accelerated node is drawn as one solid rectangle and is not split

18. OPTIM USING ACCELERATION Some renderers in the render tree can be sent "on top" This happens when an element undergoes one of several transformations such as a rotation or the application of a perspective. These transformations make the target element and its children being drawn as a solid, singular object. Joshre This sample code works for Safari IOS 5 elements. The triggers are enginedependent. -webkit -transform: translateZ(0); ! -webkit -perspective: 1000; ! -webkit -backface -visibility: hidden;

19. OPTIM ACCELERATE ALL THE THINGS ? Accelerating key elements can solve most of the visual quirks linked to the tiling effect It also has significant visual drawbacks o o Accelerated fonts are drawn as images and not the product of vectorial operations, which cancels antialiasing Most graphics suffer from the transformation that's applied to the bitmap, resulting in general blurriness. blurriness Joshre

20. OPTIM CRASHES. CRASHES EVERYWHERE. Each "master layer" (i.e. accelerated elements and grid tiles called "Compositing Layer") draws resources from the GPU Limited amount of available memory Large quantity of accelerated items tend to overflow the GPUs' buffers, causing the device to crash the application Accelerating only key elements is a necessity. Joshre Mo Mo Mo Mo

21. OPTIM REDRAWS changes, only the When the DOM the modified DOM renderers associated with are called accelerated However,their content elements tend to wholly repaint if is updated oThis is due to the fact that the accelerated element ends up as a "whole" bitmap Often-changing elements should be accelerated with caution, they can trigger the repainting of bigger elements that didn't need it. Use chrome's devtools to identify you layers' behaviour Regular

Modified

lipsum

o o ! that Ensuringtick is redraws are notofuselessly heavy at each a relevant part optimisation Joshre Accelerated

Modified

lipsum

22. OPTIM OTHER FACTORS Some properties are naturally GPU-heavy box-shadow, background-size, text-shadow, reflections, etc. o Image shims and server preprocessing can make a significant difference in rendering at the cost of overall memory or network transit Using transitions to create sliding or fading effect also triggers acceleration o Avoid redraws during animations o Animate only the strict minimum visually ; hide out of bound items, detach unimportant nodes, temporarily disable shadows/other effects o Joshre

23. OPTIM BALANCE As usual with most things, it's all about balance A limited amount of elements should be accelerated to maximise user experience improvements. oAccurately select and accelerate elements that are expected to be tiled or blinking. oDetach irrelevant elements from the rendering tree ; use visibility: hidden; to preserve the layout if needed oDraw a background in a separate, accelerated element : fewer redraws and no tiling on one of the visually most important but technically lightweight element. ! If these easily applicable (though less easily identifiable) methods fail, it's time to approach different angles. Joshre

24. DIFFERENT ANGLES

25. STEP BACK UMA mobile MostAndroidsdevices (iPhones and included) do not provide dedicated GPU memory Heavy Code ! ! Unified Memory Architecture A pool of memory both GPU and CPU can access of the Heavy solicitationprocessing memory via CPU while ( 1 ) ! { Infinite movie posters list scrolling console.log('derp'); } (calculations, main routine) will decrease available memory for the GPU ... and vice versa. Joshre SHARED MEMORY

26. STANDARD CHECKLIST Free up memory o Check for memory leaks (which is another presentation altogether) o Unload unnecessary collections / templates / etc. o Chunks of data can be swapped with localstorage (slow) ! Flatten the DOM o Minimize pure-layout nodes o CSS3 when applicable enhances pure css layouting abilities at minimal cost o Minimize 's, use data-url="" and events instead Joshre

27. DETACHING DOM FRAGMENTS DOM subtrees can be kept in memory without being attached to the main tree In this state they stay loaded in memory and parsed but are excluded from the rendering at every step Detaching / Attaching subtrees to the DOM is fairly fast, as opposed to parsing / loading This can be especially effective for scrollview children... Joshre

28. IMITATING TABLEVIEWS Long and rich lists are often the core problem in terms of performance It is often necessary to control the quantity of items displayed at once ; the way native SDKs manage table cells. Progressively detach / attach elements depending on the position in the scroll view Preserve the height of the scrollview with a leading

which can be resized ! Quite effective when lines are reasonably light Joshre

29. RENDERING ON CANVASES Dense, graphical areas can be rendered onto elements o Reduces the number of nodes drastically o should act as a bitmap once fully drawn o Can abstract large rows/columns of images Loses any sense of structure ; no more DOM o Can impede basic and essential features Support still edgy on some devices ! Very efficient for dense graphical areas. Can become expensive in development time. Joshre

30. THIS IS THE END You are now free to hit ESC.