wiki:April 2012 MeetingRethinkingRendering

Version 3 (modified by, 9 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
  • 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