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