(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

* 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?
  * jchaffraix: maybe you shouldn't inherit from RenderBlock if you aren't actually a "block" in the CSS box model sense
 
* eseidel: a render layer defines its own coordinate space (and a z-order) - so when you need your own coordinates (e.g., abs positioning), you need a layer

## Security Issues w/ the current architecture

* jchaffraix: if the render tree gets confused, the code does bad things with pointers
* jchaffraix: potentially layout should never modify the render tree (during layout) 
  * example: don't destroy / reparent things during run-ins
  * inferno: e.g., during flexbox layout, this can leave other objects with dangling pointers to stale objects
* rniwa: how do you handle continuations (generated content, bidirectional text)?
  * during style recalc?

* eseidel: the render tree is really just a big cache, and maybe that's the problem
  * we hope that nothing is stale at that point
  * layout is supposed to make things not be stale

* jchaffraix: are continuations strictly defined by the dom tree? 
  * inferno: they shouldn't be (aren't) created during layout (?)
  * eseidel: that is not the invariant today - blocks are created and destroyed during layout 
  * jamesr: that only happens during style recalc
  * eseidel: I am misinformed :)

* rniwa: why do counters need to compute the counter during layout (and not style calc)
  * jchaffraix: dunno, need to redesign counters? possible could be done during pre layout

* render trees use raw pointers are over the place
  * could we do something like weak ptrs instead so that collection is well defined (as long as it doesn't impact performance)
  * what happened to the experiment of holding references to dom nodes?
    * jamesr: 5% perf impact (follow up w/ ojan?)
    * rniwa: you could hold on to a lot of nodes until script invocation ends
      * rniwa: needs a lot more investigation

* rniwa: jamesr, are you adding assertions / invariants to the code?
  * jamesr: did some, but there were too many exceptions to be able to turn things on
  * jamesr: whenever an invariant failed, it always lead to a security bug, it seemed
  * jamesr: we need to document what the invariants should be (e.g., anonymous objects shouldn't have a layer)
  * jchaffraix: perhaps this is part of "create a new object"
  
* jchaffraix: the whole problem of the render tree is corner cases - you always forget one (or 10%)
    * rniwa: e.g., people always forget editing / designMode
  * jchaffraix: responsibility is also spread out, e.g. overflow
  * smfr: a lot of this has been done for optimization
  * jchaffraix: should we be more strict about who is allowed to know about who?
    * smfr: probably, but we're very performance-sensitive
    * eseidel: we might be too sensitive here