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

Timestamp:

Apr 22, 2014 10:24:28 AM (10 years ago)

Author:

Bem Jones-Bey

Comment:

--

2014 Meeting Pointers and Iterators

@@ +1 @@
+== 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