= Display Lists = == 2015 Display List Experiment == * Recording GraphicsContext calls, and playing them back later * Drive GraphicsContext cleanup * Perf gains * Per-compositing layer * Logging == Future == * Display list mutation (some CSS animations, GIFs, scrolling) * Repaint * Occlusion detection, state change optimization * Shared display list segments * Paint-to-paint caching * Text = Display List Rendering = == What is display list rendering? == * Reduces expensive traversal of the render tree for each tile * Converts some paints to pure display-list operations, such as: ** GIF animation, CSS animations, scrolling * We can also potentially use display lists to paint off the main thread == What can we gain from display lists? == * Many optimizations we can fit in to our existing code as one-off optimizations, but display lists provide a common way of reasoning about these optimizations * Make WK code more efficient by eliminating useless repaints, using precomputed display lists ** Better culling (accurate extent information): we can use the display list to compute the exact bounds of what needs to be repainted, allowing us to tighten the repaint rect ** Can optimize noops out of the painting code ** Occlusion detection and clipping ** Can reorder operations for better batching * Reuse display lists in a single painting pass (e.g. SVG images, ) * Can keep display lists around between painting passes (e.g. across different tiles) * We have opportunities to cache display lists ** Text rendering: don’t have to recompute kerning, glyphs (?) * We can log all the painting commands that happen ** Developer tools implications: can use display list logs to tell which elements are the most costly to render, or perhaps scrub through the painting of a page ** Can also use display lists to help layout testing == What are the biggest challenges? == * For painting off the main thread: CA doesn’t play well with this, GraphicsContext is non-threadsafe * Map of RenderObject -> DisplayItem could use a lot of memory * Measuring performance gain: often run into unexpected perf issues, weird/unexpected CG behaviors * Testing: make sure the switch to display lists doesn’t introduce regressions == The prototype == * For a particular call into GraphicsContext, we record what the GraphicsContext does * Packages up params of calls to GraphicsContext * updateItemExtent(DrawingItem): This gets the local bounds of the item and maps into global coordinates taking transforms/shadows into account == Performance data == * Perf relative to non-display-list mode is similar on iPad and iMac * Text is strange – should be much faster, but we seem to spend a lot of time waiting for CG * In cases where perf goes down, we spend less time in web code – we seem to get throttled by CG * Paint time dwarfs record time * Even if we don’t see a performance gain, we might be using fewer CPU cycles, so less power == Next steps == * Contact other teams (e.g. CA). Maybe get a way from CA to draw from another thread? * Continue investigating perf regressions vs. normal rendering * Consider cleaning up GraphicsContext * Form controls currently grab the platform context out of the context, so they need to be optimized to work with display lists == Other comments == * Renderer knows about the display lists it generates * Geoff: if we can fix the 2 bugs with display lists, it would give us matching and/or better perf across the board * Sam: may want to consider a tree structure for when we want to mutate display list operations efficiently * Simon: maybe lower the level of diplay list recording to the platform context