Your SlideShare is downloading. ×
0
Rendering Optimizations
A few insights on how to cope with high quality, rich webapps
Apr. 2013

Arthur Jamain
arthur@josh...
CONTEXT
What’s going on and where ?
CONTEXT

TECHNOLOGIES

• Rich HTML5/JS Applications
expected to behave like a
native app.


• Basic access to native
featu...
CONTEXT

OBJECTIVES

• High expectations of UX quality

• Heavy content : lengthy videos
or images lists, overall rich UIs...
CONTEXT

VALIDITY

• Most of the concepts described in this presentation
are heavily platform dependent


• Rendering engi...
WEBAPPS
General Considerations
WEBAPPS

RUNTIME

• A Native Webview runs the HTML5 App
• Alongside are plugins : camera, sensors, etc.
• The Webview is e...
WEBAPPS

RENDERING

• The one Webview's engine renders the whole
app

o We're talking UI here, it is fairly easy to defer
...
PAGE RENDERING
In the kingdom of the blind …
RENDERING

WHAT IS IT ?

• The process of

JS

HTML
load, parse

transforming the document
into what we see on our

CSS

A...
RENDERING

THE RENDER TREE

• Ordered tree of visual elements (“renderers”) representing the
DOM elements


• Enables pain...
RENDERING

THE RENDER TREE

Check these options in
Chrome&Co. to visualize
the content rectangles

• Each renderer has chi...
RENDERING

LAYERS !

• The browser then draws a
•
•
•

grid of rectangles.
Controlled-size layers —
hence keeping several
...
Stop !
Recap time.
RECAP

DOM Tree

• Initially, and whenever the drawing loop ticks :!
o The DOM nodes that have changed spawn

Render Tree
...
RENDERING

OPTIMIZATIONS
HACK AROUND
OPTIM

HARDWARE ACCELERATION

• Tiling may produce weird

•
•

visual effects

o They are drawn on a single
thread, asynch...
OPTIM

USING ACCELERATION

• Some renderers in the render
•

•

tree can be sent "on top"
This happens when an element
und...
OPTIM

ACCELERATE ALL THE THINGS ?

• Accelerating key elements can solve most of the
visual quirks linked to the tiling e...
OPTIM

CRASHES. CRASHES EVERYWHERE.

• Each "master layer" (i.e.
•
•
•

accelerated elements and grid tiles
— called "Comp...
OPTIM

REDRAWS

changes, only the
• When the DOM the modified DOM renderers
associated with
are called
accelerated
• Howev...
OPTIM

OTHER FACTORS

• Some properties are naturally GPU-heavy

box-shadow, background-size, text-shadow, reflections,
et...
OPTIM

BALANCE

• As usual with most things, it's all about balance
• A limited amount of elements should be accelerated t...
DIFFERENT ANGLES
STEP BACK

UMA

mobile
• MostAndroidsdevices (iPhones
and
included) do not
provide dedicated GPU
memory

Heavy Code

!
!

...
STANDARD CHECKLIST
• Free up memory
o

Check for memory leaks (which is another
presentation altogether)
o Unload unnecess...
DETACHING DOM FRAGMENTS
• DOM subtrees can be kept in memory without being
attached to the main tree


• In this state the...
IMITATING TABLEVIEWS
• Long and rich lists are often the core problem in terms
of performance
• It is often necessary to c...
RENDERING ON CANVASES
• Dense, graphical areas can be rendered onto <canvas> elements
o

Reduces the number of nodes drast...
THIS IS THE END
You are now free to hit ESC.
Upcoming SlideShare
Loading in...5
×

Webapp Rendering and Optimization.

3,891

Published on

This small presentation tries to synthesise the behaviour of a web browser's rendering engine as simply as possible. It also proposes a few tricks we've used internally to cope with very resource-demanding webapps.

Published in: Technology, Art & Photos
1 Comment
2 Likes
Statistics
Notes
No Downloads
Views
Total Views
3,891
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
9
Comments
1
Likes
2
Embeds 0
No embeds

No notes for slide

Transcript of "Webapp Rendering and Optimization."

  1. 1. Rendering Optimizations A few insights on how to cope with high quality, rich webapps Apr. 2013 Arthur Jamain arthur@joshfire.com
  2. 2. CONTEXT What’s going on and where ?
  3. 3. CONTEXT TECHNOLOGIES • Rich HTML5/JS Applications expected to behave like a native app. • Basic access to native features • Low resources, high-end display Joshfire
  4. 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. Joshfire
  5. 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 Joshfire
  6. 6. WEBAPPS General Considerations
  7. 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 Joshfire
  8. 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 Webview’s (hence, the app) resource consumption can only be done by altering the JS / CSS / HTML code which determines what is rendered and how. Joshfire
  9. 9. PAGE RENDERING In the kingdom of the blind …
  10. 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 Joshfire
  11. 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 Joshfire
  12. 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 children’s ones. Joshfire
  13. 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 Joshfire Html content that spans on the whole page. Note that the grey element is split and drawn among 4 tiles
  14. 14. Stop ! Recap time.
  15. 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 Joshfire
  16. 16. RENDERING OPTIMIZATIONS HACK AROUND
  17. 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. Joshfire The “accelerated” node is drawn as one solid rectangle and is not split
  18. 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. Joshfire 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. 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 Joshfire
  20. 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. Joshfire Mo Mo Mo Mo
  21. 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 <div> Modified <p>lipsum</p> o o ! that • Ensuringtick is redraws are notofuselessly heavy at each a relevant part optimisation Joshfire Accelerated <div> Modified <p>lipsum</p>
  22. 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 • Joshfire
  23. 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. Joshfire
  24. 24. DIFFERENT ANGLES
  25. 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. Joshfire SHARED MEMORY
  26. 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 <a>'s, use data-url="" and events instead Joshfire
  27. 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... Joshfire
  28. 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 <div> which can be resized ! • Quite effective when lines are reasonably light Joshfire
  29. 29. RENDERING ON CANVASES • Dense, graphical areas can be rendered onto <canvas> 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. Joshfire
  30. 30. THIS IS THE END You are now free to hit ESC.
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×