ruffle/core/src/xml.rs

//! Garbage-collectable XML DOM impl

mod iterators;
mod tree;

pub use tree::{XmlNode, ELEMENT_NODE, TEXT_NODE};
Add rudimentary custom DOM impl on top of `quick_xml`. `quick_xml` was chosen due to it's high performance and support for zero-copy use cases. However, we are not using `minidom`, which is the already-extant DOM impl that uses `quick_xml` as it's parsing provider. This is because `minidom` nodes are not amenable to garbage collection. Specifically: we want to be able to construct a new `Object` variant that holds part of an XML node. However, `minidom::Element` directly owns it's children, meaning that we can't hold references to it from within `Object` while also keeping those objects to the `'gc` lifetime. Hence, we provide a GC-exclusive DOM implementation. I ruled out solutions such as holding an entire XML tree in an `Rc` and having AVM objects that shadow them. This works for `SwfSlice` because indexing an array is cheap; but traversing a tree can get very expensive. XML is used in many places in Flash Player, so it's important that we treat it like a first-class citizen. 2019-12-20 03:19:22 +00:00			`//! Garbage-collectable XML DOM impl`

Add the ability to `walk` through an XML tree. This yields nodes as `Step`s. This allows keeping track of the structure of the tree as you walk through descendents, as each element will be yielded twice: both as a `Step::In` and as a `Step::Out`. Non-element nodes will be yielded once as a `Step::Around`. I'm adding `walk` iteration specifically to avoid having to write certain methods recursively. Existing recursive callers of `children` should probably be updated to `walk` the tree and maintain a separate `Vec` stack. 2020-01-22 04:33:47 +00:00			`mod iterators;`
Add rudimentary custom DOM impl on top of `quick_xml`. `quick_xml` was chosen due to it's high performance and support for zero-copy use cases. However, we are not using `minidom`, which is the already-extant DOM impl that uses `quick_xml` as it's parsing provider. This is because `minidom` nodes are not amenable to garbage collection. Specifically: we want to be able to construct a new `Object` variant that holds part of an XML node. However, `minidom::Element` directly owns it's children, meaning that we can't hold references to it from within `Object` while also keeping those objects to the `'gc` lifetime. Hence, we provide a GC-exclusive DOM implementation. I ruled out solutions such as holding an entire XML tree in an `Rc` and having AVM objects that shadow them. This works for `SwfSlice` because indexing an array is cheap; but traversing a tree can get very expensive. XML is used in many places in Flash Player, so it's important that we treat it like a first-class citizen. 2019-12-20 03:19:22 +00:00			`mod tree;`

xml: Refactor `XmlNode` creation methods Unify the previous 3 creation methods to a single `XmlNode::new`. This allows supporting arbitrary `nodeType` values passed to the `XMLNode` constructor. 2022-04-08 21:28:19 +00:00			`pub use tree::{XmlNode, ELEMENT_NODE, TEXT_NODE};`