Version 1 (modified by 10 years ago) ( diff ) | ,
---|
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
Attachments (2)
- New WebKit smart pointers.pdf (1.8 MB ) - added by 10 years ago.
- element iterators.pdf (103.1 KB ) - added by 10 years ago.
Download all attachments as: .zip