| 1 | == Iterators == |
| 2 | |
| 3 | === Element iterators === |
| 4 | |
| 5 | Traverse the dom tree with an iterator |
| 6 | 2 iterator constructor functions |
| 7 | |
| 8 | * childrenOfType<ElementClass> |
| 9 | * descendantsOfType<ElementClass> |
| 10 | |
| 11 | Use as an auto& in the for, since the type name is in the call |
| 12 | |
| 13 | * is const if you have a const iterator, otherwise is non-const |
| 14 | * usually don't write the const explicitly |
| 15 | |
| 16 | Works on classes that have isElementOfType<> function |
| 17 | * Mostly auto generated from HTMLNames.in |
| 18 | |
| 19 | Right now, can only specify type, but maybe take a lambda in the future to be |
| 20 | able to give a more expressive predicate |
| 21 | |
| 22 | There is a childrenOfType for the RenderTree. It isn't automatically generated, |
| 23 | however. |
| 24 | |
| 25 | Wondering what the perf implications would be if the asserts about mutating the |
| 26 | dom tree when iterating over it were made release asserts. |
| 27 | |
| 28 | === Other === |
| 29 | |
| 30 | New macro called NODE_TYPE_CASTS that adds type casting methods. |
| 31 | |
| 32 | Wondering what the perf implications would be to make type cast asserts release |
| 33 | asserts. |
| 34 | |
| 35 | === Next steps === |
| 36 | |
| 37 | RenderTree iterations |
| 38 | |
| 39 | * auto generation |
| 40 | * asserts for mutation of tree when mutation happens |
| 41 | |
| 42 | These are Element iterators, you can't get Nodes out of them. Don't want people |
| 43 | iterating over a mixture. |
| 44 | |
| 45 | == Ref & PassRef - pointers == |
| 46 | |
| 47 | === Ref<T> === |
| 48 | * Always points to an object |
| 49 | * Always holds a strong reference to that object |
| 50 | * Intiliazed with a T& or a PassRef<t> |
| 51 | * Use .get() to access the T& |
| 52 | * doesn't have to make null checks like RefPtr does |
| 53 | |
| 54 | === PassRef<t> === |
| 55 | * Like PassRefPtr<T>, bt never null |
| 56 | * used to initialize Ref<T> |
| 57 | * Must be sunk into a Ref<T> or explicitly dropRef()'ed |
| 58 | * will assert if this doesn't happen and the PassRef goes out of scope |
| 59 | * doesn't generate null checks or calls to destructor, like PassRefPtr |
| 60 | * never have to inline any destructor |
| 61 | |
| 62 | === RenderPtr<T> === |
| 63 | * Basically an OwnPtr<RnederObjct> |
| 64 | * Calls RenderObject::destroy() instead of ~RenderObject() |
| 65 | * Goal is to move the rendering code to using smart pointers for ownership |
| 66 | clarity and general safety |
| 67 | |
| 68 | * Good to have weak pointers on the render tree (WeakRenderPtr) |
| 69 | |
| 70 | * if you use a unique_ptr after you've moved it's value away, you get a compile time warning. How does that work? |
| 71 | |
| 72 | == Extra innings == |
| 73 | |
| 74 | === Atomic Strings === |
| 75 | |
| 76 | Could make then 32 bit integers, which means we could make a bunch of them |
| 77 | compile time constants. Then we could switch on integers instead of pointers. |
| 78 | This hasn't been done yet because it is huge and involved a lot of full |
| 79 | rebuilds. This was the way the engine used to work. |
| 80 | |
| 81 | === Perf === |
| 82 | |
| 83 | There's lots of low hanging fruit in places like the HTML parser. |
| 84 | |
| 85 | === Simple Line Layout === |
| 86 | |
| 87 | Uses a very simple and compact "Run" data structure, about 10% of the size of using the normal Line Boxes |
| 88 | In SimpleLineLayout.{h,cpp} |
| 89 | |
| 90 | * canUseFor function says if simple line layout can be used |
| 91 | |
| 92 | Only handles a few cases, but these are extremely common cases, about 40% of the web |
| 93 | Has a runtime flag to turn on/off |
| 94 | Most of the speedup is by having better data layout |