| | 65 | * render trees use raw pointers are over the place |
| | 66 | * could we do something like weak ptrs instead so that collection is well defined (as long as it doesn't impact performance) |
| | 67 | * what happened to the experiment of holding references to dom nodes? |
| | 68 | * jamesr: 5% perf impact (follow up w/ ojan?) |
| | 69 | * rniwa: you could hold on to a lot of nodes until script invocation ends |
| | 70 | * rniwa: needs a lot more investigation |
| | 71 | |
| | 72 | * rniwa: jamesr, are you adding assertions / invariants to the code? |
| | 73 | * jamesr: did some, but there were too many exceptions to be able to turn things on |
| | 74 | * jamesr: whenever an invariant failed, it always lead to a security bug, it seemed |
| | 75 | * jamesr: we need to document what the invariants should be (e.g., anonymous objects shouldn't have a layer) |
| | 76 | * jchaffraix: perhaps this is part of "create a new object" |
| | 77 | |
| | 78 | * jchaffraix: the whole problem of the render tree is corner cases - you always forget one (or 10%) |
| | 79 | * rniwa: e.g., people always forget editing / designMode |
| | 80 | * jchaffraix: responsibility is also spread out, e.g. overflow |
| | 81 | * smfr: a lot of this has been done for optimization |
| | 82 | * jchaffraix: should we be more strict about who is allowed to know about who? |
| | 83 | * smfr: probably, but we're very performance-sensitive |
| | 84 | * eseidel: we might be too sensitive here |
