Version 2 (modified by 13 years ago) ( diff ) | ,
---|
(Moderator: jchaffraix, Scribe: dpranke)
(Notes in progress)
How can we get more people hacking on rendering?
- accelerated compositing is tied to a layer (a very old concept)
- can we make layers better or faster?
- can we talk about security and the impact of specific design decisions in the render tree (inferno, bethdakin?)
- jchaffraix: from study tables, thinks layers are the wrong abstraction
- as a general rule, the render object knows what its own structure should be
- because layers are generic, they don't know and have to do more work
- they do too much
- repainting
- clipping
- compositing
- stacking
- scrolling
- as a general rule, the render object knows what its own structure should be
- eseidel: layers are designed to allow the rendering tree to be lightweight
- layers exist to handle the more "advanced" features of rendering
- smfr: layers designed to solve problems like scrolling and clipping that affect a set of render objects in one go
- eseidel: what are the problems we're trying to solve?
- (??) need render layers to support z-index (for svg 2.0 and z-stacking not in document order)
- jamesr: we want to composited into svg
- enne: rendering / layers are hard to test
- dave barton: mathml is very painful - math layout is bottom-up from the children of the node, not top-down left-to-right on the page
- jamesr / jchaffraix: tables are very similar
- eseidel: if you call setNeedsLayout(False), you should be able to do whatever you want inside your own elements
- jchaffraix: this means we don't reuse other code
- eseidel: there are other layout models other than the renderboxmodel
- eseidel: also there's computePreferredWidths()
- dave barton: this is kinda what he does in mathml
- jamesr: maybe mathml shouldn't be deriving from renderboxmodelobject?
- dave barton: but we do use a lot of it - maybe this is more a question about writing your own render object and should be in the other talk?
Note:
See TracWiki
for help on using the wiki.