| | 1 | (Moderator: jchaffraix, Scribe: dpranke) |
| | 2 | |
| | 3 | (Notes in progress) |
| | 4 | |
| | 5 | How can we get more people hacking on rendering? |
| | 6 | |
| | 7 | * accelerated compositing is tied to a layer (a very old concept) |
| | 8 | * can we make layers better or faster? |
| | 9 | |
| | 10 | * can we talk about security and the impact of specific design decisions in the render tree (inferno, bethdakin?) |
| | 11 | |
| | 12 | * jchaffraix: from study tables, thinks layers are the wrong abstraction |
| | 13 | * as a general rule, the render object knows what its own structure should be |
| | 14 | * because layers are generic, they don't know and have to do more work |
| | 15 | * they do too much |
| | 16 | * repainting |
| | 17 | * clipping |
| | 18 | * compositing |
| | 19 | * stacking |
| | 20 | * scrolling |
| | 21 | |
| | 22 | * eseidel: layers are designed to allow the rendering tree to be lightweight |
| | 23 | * layers exist to handle the more "advanced" features of rendering |
| | 24 | * smfr: layers designed to solve problems like scrolling and clipping that affect a set of render objects in one go |
