Changes between Version 4 and Version 5 of DisplayLists

Nov 17, 2015 10:05:32 AM (8 years ago)
Jon Davis



  • DisplayLists

    v4 v5  
    1717* Paint-to-paint caching
    1818  * Text
     21= Display List Rendering =
     23== What is display list rendering? ==
     25* Reduces expensive traversal of the render tree for each tile
     26* Converts some paints to pure display-list operations, such as:
     27** GIF animation, CSS animations, scrolling
     28* We can also potentially use display lists to paint off the main thread
     30== What can we gain from display lists? ==
     32* 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
     33* Make WK code more efficient by eliminating useless repaints, using precomputed display lists
     34** 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
     35** Can optimize noops out of the painting code
     36** Occlusion detection and clipping
     37** Can reorder operations for better batching
     38* Reuse display lists in a single painting pass (e.g. SVG images, <use>)
     39* Can keep display lists around between painting passes (e.g. across different tiles)
     40* We have opportunities to cache display lists
     41** Text rendering: don’t have to recompute kerning, glyphs (?)
     42* We can log all the painting commands that happen
     43** 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
     44** Can also use display lists to help layout testing
     46== What are the biggest challenges? ==
     48* For painting off the main thread: CA doesn’t play well with this, GraphicsContext is non-threadsafe
     49* Map of RenderObject -> DisplayItem could use a lot of memory
     50* Measuring performance gain: often run into unexpected perf issues, weird/unexpected CG behaviors
     51* Testing: make sure the switch to display lists doesn’t introduce regressions
     53== The prototype ==
     55* For a particular call into GraphicsContext, we record what the GraphicsContext does
     56* Packages up params of calls to GraphicsContext
     57* updateItemExtent(DrawingItem): This gets the local bounds of the item and maps into global coordinates taking transforms/shadows into account
     59== Performance data ==
     61* Perf relative to non-display-list mode is similar on iPad and iMac
     62* Text is strange – should be much faster, but we seem to spend a lot of time waiting for CG
     63* In cases where perf goes down, we spend less time in web code – we seem to get throttled by CG
     64* Paint time dwarfs record time
     65* Even if we don’t see a performance gain, we might be using fewer CPU cycles, so less power
     67== Next steps ==
     69* Contact other teams (e.g. CA). Maybe get a way from CA to draw from another thread?
     70* Continue investigating perf regressions vs. normal rendering
     71* Consider cleaning up GraphicsContext
     72* Form controls currently grab the platform context out of the context, so they need to be optimized to work with display lists
     74== Other comments ==
     76* Renderer knows about the display lists it generates
     77* Geoff: if we can fix the 2 bugs with display lists, it would give us matching and/or better perf across the board
     78* Sam: may want to consider a tree structure for when we want to mutate display list operations efficiently
     79* Simon: maybe lower the level of diplay list recording to the platform context