| | 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 | |
