= Rethinking rendering = (Moderator: jchaffraix, Scribe: dpranke) == 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 == Repainting == * jchaffraix: who knows how repainting actually works? (laughter in the room) * there are lots of ways that it can get triggered * what would a good architecture be for a general way of repainting? * smfr: it is definitely confusing and buggy - compositing made things worse - but it's not clear what better ideas are * jamesr: it's also very hard to construct good tests - maybe we need better hooks for testing? * paint everything, make some changes that hopefully cause invalidation, paint again, and hope that the PNG displays something useful * we don't necessarily just take the union of invalid rects * maybe you can use layoutTestController.display() - see a list of rectangles that got sent out, rather than the end result * jamesr: scrolling also complicates things (don't necessarily get the blit at all) == Splitting up RenderLayer? == * jchaffraix: first, hack off some of the bits to other things * then split up the core object * ex: overflow: hidden * just needs to hold the clipped rect? * doesn't need scroll bars or a full layer * (smfr: of course, you can still scroll via js) * smfr: we should fix the cost of updateLayerPositions - we don't have a dirty bit * jchaffraix: last time he tried to figure out what was dirty, it was hard * ??: can we do both at the same time - create a lightweight render layer *and* split out / abstract things better * eseidel: do most render layers have graphics layers? * smfr / jamesr: no - only a few can / do * eseidel: there's at least two roles: * i have rare (uncommon) data * i have something that needs to be in the compositing stack * smfr: maybe it's more something that modifies hit testing (e.g., filters) * smfr: maybe the responsibility for doing painting should be a separate class, hit testing should be a separate class, stacking should be a separate class? * eseidel: maybe (Following on the regions discussion) break things out more things into an optional hasA relationship? * smfr: possibly fix parts of SVG so that they can use these things (e.g., foreign objects) * jamesr: you need painting, hit testing * jchaffraix: maybe z-ordering is optional (?) * smfr: certainly some layers need z-ordering * smfr: it's not clear that you wouldn't recreate the same algorithm (go layer at a time and then paint every object in the layer) * eseidel: some things are very specific to the CSS box model (the 7 steps of rendering a box) but maybe some things can be reused more generally (e.g., z-ordering) * smfr: things may not be so separable, but maybe some things can be optional * (??): perhaps the confusion is over mixing functionality and ownership - there's only one tree, but we split the functionality over multiple classes * maybe you could have one tree with different attributes instead of different subtrees (?) - this is a different way to look at the problem but hasn't really been investigated * smfr: you might end up re-creating trees just so you can keep track of what's going on during traversal * (??): maybe they would at least be homogenous trees in that case * (??): maybe render layers shouldn't be boxes, because they don't need all of the aspects of a box