Your SlideShare is downloading. ×
Webapp Rendering and Optimization.
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Webapp Rendering and Optimization.

3,786
views

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 …

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,786
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
9
Comments
1
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Rendering Optimizations A few insights on how to cope with high quality, rich webapps Apr. 2013 Arthur Jamain arthur@joshfire.com
  • 2. CONTEXT What’s 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 Joshfire
  • 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. 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. 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 Joshfire
  • 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. 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 Joshfire
  • 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. 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. 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. 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 Joshfire
  • 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. Joshfire 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. 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. 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. 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. 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. 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. 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. 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. Joshfire 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 <a>'s, use data-url="" and events instead Joshfire
  • 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. 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. 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. THIS IS THE END You are now free to hit ESC.

×