wiki:DisplayLists

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, <use>)
  • 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
Last modified 6 years ago Last modified on Nov 17, 2015 10:06:06 AM