Changes between Version 4 and Version 5 of DisplayLists


Ignore:
Timestamp:
Nov 17, 2015 10:05:32 AM (7 years ago)
Author:
Jon Davis
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DisplayLists

    v4 v5  
    1717* Paint-to-paint caching
    1818  * Text
     19
     20
     21= Display List Rendering =
     22
     23== What is display list rendering? ==
     24
     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
     29
     30== What can we gain from display lists? ==
     31
     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
     45
     46== What are the biggest challenges? ==
     47
     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
     52
     53== The prototype ==
     54
     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
     58
     59== Performance data ==
     60
     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
     66
     67== Next steps ==
     68
     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
     73
     74== Other comments ==
     75
     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
     80