1. Rendering Optimizations A few insights on how to cope with
high quality, rich webapps Apr. 2013 Arthur Jamain
[email protected]
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