== Iterators ==

=== Element iterators ===

Traverse the dom tree with an iterator
2 iterator constructor functions

 * childrenOfType<ElementClass>
 * descendantsOfType<ElementClass>

Use as an auto& in the for, since the type name is in the call

 * is const if you have a const iterator, otherwise is non-const
 * usually don't write the const explicitly

Works on classes that have isElementOfType<> function
 * Mostly auto generated from HTMLNames.in

Right now, can only specify type, but maybe take a lambda in the future to be
able to give a more expressive predicate

There is a childrenOfType for the RenderTree. It isn't automatically generated,
however.

Wondering what the perf implications would be if the asserts about mutating the
dom tree when iterating over it were made release asserts.

=== Other ===

New macro called NODE_TYPE_CASTS that adds type casting methods.

Wondering what the perf implications would be to make type cast asserts release
asserts.

=== Next steps ===

RenderTree iterations

 * auto generation
 * asserts for mutation of tree when mutation happens

These are Element iterators, you can't get Nodes out of them. Don't want people
iterating over a mixture.

== Ref & PassRef - pointers ==

=== Ref<T> ===
 * Always points to an object
 * Always holds a strong reference to that object
 * Intiliazed with a T& or a PassRef<t>
 * Use .get() to access the T&
 * doesn't have to make null checks like RefPtr does

=== PassRef<t> ===
  * Like PassRefPtr<T>, bt never null
  * used to initialize Ref<T>
  * Must be sunk into a Ref<T> or explicitly dropRef()'ed
    * will assert if this doesn't happen and the PassRef goes out of scope
  * doesn't generate null checks or calls to destructor, like PassRefPtr
    * never have to inline any destructor

=== RenderPtr<T> ===
  * Basically an OwnPtr<RnederObjct>
  * Calls RenderObject::destroy() instead of ~RenderObject()
  * Goal is to move the rendering code to using smart pointers for ownership
    clarity and general safety

* Good to have weak pointers on the render tree (WeakRenderPtr)

* if you use a unique_ptr after you've moved it's value away, you get a compile time warning. How does that work?

== Extra innings ==

=== Atomic Strings ===

Could make then 32 bit integers, which means we could make a bunch of them
compile time constants. Then we could switch on integers instead of pointers.
This hasn't been done yet because it is huge and involved a lot of full
rebuilds. This was the way the engine used to work.

=== Perf ===

There's lots of low hanging fruit in places like the HTML parser.

=== Simple Line Layout ===

Uses a very simple and compact "Run" data structure, about 10% of the size of using the normal Line Boxes
In SimpleLineLayout.{h,cpp}

 * canUseFor function says if simple line layout can be used

Only handles a few cases, but these are extremely common cases, about 40% of the web
Has a runtime flag to turn on/off
Most of the speedup is by having better data layout