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