Changes between Version 4 and Version 5 of April 2012 MeetingRethinkingRendering


Ignore:
Timestamp:
Apr 19, 2012 12:18:19 PM (9 years ago)
Author:
dpranke@chromium.org
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • April 2012 MeetingRethinkingRendering

    v4 v5  
    8484    * eseidel: we might be too sensitive here
    8585
     86## Repainting
     87
     88* jchaffraix: who knows how repainting actually works? (laughter in the room)
     89  * there are lots of ways that it can get triggered
     90  * what would a good architecture be for a general way of repainting?
     91  * smfr: it is definitely confusing and buggy - compositing made things worse - but it's not clear what better ideas are
     92  * jamesr: it's also very hard to construct good tests - maybe we need better hooks for testing?
     93    * paint everything, make some changes that hopefully cause invalidation, paint again, and hope that the PNG displays something useful
     94    * we don't necessarily just take the union of invalid rects
     95    * maybe you can use layoutTestController.display() - see a list of rectangles that got sent out, rather than the end result
     96  * jamesr: scrolling also complicates things (don't necessarily get the blit at all)
     97
     98## Splitting up RenderLayer?
     99
     100* jchaffraix: first, hack off some of the bits to other things
     101* then split up the core object
     102* ex: overflow: hidden
     103  * just needs to hold the clipped rect?
     104  * doesn't need scroll bars or a full layer
     105  * (smfr: of course, you can still scroll via js)
     106  * smfr: we should fix the cost of updateLayerPositions - we don't have a dirty bit
     107  *  jchaffraix: last time he tried to figure out what was dirty, it was hard
     108* ??: can we do both at the same time - create a lightweight render layer *and* split out / abstract things better
     109
     110* eseidel: do most render layers have graphics layers?
     111  * smfr / jamesr: no - only a few can / do
     112
     113* eseidel: there's at least two roles:
     114  * i have rare (uncommon) data
     115  * i have something that needs to be in the compositing stack
     116  * smfr: maybe it's more something that modifies hit testing (e.g., filters)
     117  * 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?
     118
     119* eseidel: maybe (Following on the regions discussion) break things out more things into an optional hasA relationship?
     120  * smfr: possibly fix parts of SVG so that they can use these things (e.g., foreign objects)
     121  * jamesr: you need painting, hit testing
     122  * jchaffraix: maybe z-ordering is optional (?)
     123  * smfr: certainly some layers need z-ordering
     124  * 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)
     125
     126* 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)
     127  * smfr: things may not be so separable, but maybe some things can be optional
     128
     129* (??): perhaps the confusion is over mixing functionality and ownership - there's only one tree, but we split the functionality over multiple classes
     130  * 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
     131 
    86132
    87133
     
    91137
    92138
     139