| 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 | |