Changes between Initial Version and Version 1 of 2014 Meeting Pointers and Iterators


Ignore:
Timestamp:
Apr 22, 2014, 10:24:28 AM (10 years ago)
Author:
Bem Jones-Bey
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • 2014 Meeting Pointers and Iterators

    v1 v1  
     1== Iterators ==
     2
     3=== Element iterators ===
     4
     5Traverse the dom tree with an iterator
     62 iterator constructor functions
     7
     8 * childrenOfType<ElementClass>
     9 * descendantsOfType<ElementClass>
     10
     11Use 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
     16Works on classes that have isElementOfType<> function
     17 * Mostly auto generated from HTMLNames.in
     18
     19Right now, can only specify type, but maybe take a lambda in the future to be
     20able to give a more expressive predicate
     21
     22There is a childrenOfType for the RenderTree. It isn't automatically generated,
     23however.
     24
     25Wondering what the perf implications would be if the asserts about mutating the
     26dom tree when iterating over it were made release asserts.
     27
     28=== Other ===
     29
     30New macro called NODE_TYPE_CASTS that adds type casting methods.
     31
     32Wondering what the perf implications would be to make type cast asserts release
     33asserts.
     34
     35=== Next steps ===
     36
     37RenderTree iterations
     38
     39 * auto generation
     40 * asserts for mutation of tree when mutation happens
     41
     42These are Element iterators, you can't get Nodes out of them. Don't want people
     43iterating 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
     76Could make then 32 bit integers, which means we could make a bunch of them
     77compile time constants. Then we could switch on integers instead of pointers.
     78This hasn't been done yet because it is huge and involved a lot of full
     79rebuilds. This was the way the engine used to work.
     80
     81=== Perf ===
     82
     83There's lots of low hanging fruit in places like the HTML parser.
     84
     85=== Simple Line Layout ===
     86
     87Uses a very simple and compact "Run" data structure, about 10% of the size of using the normal Line Boxes
     88In SimpleLineLayout.{h,cpp}
     89
     90 * canUseFor function says if simple line layout can be used
     91
     92Only handles a few cases, but these are extremely common cases, about 40% of the web
     93Has a runtime flag to turn on/off
     94Most of the speedup is by having better data layout