> You'd need a record of the lowest common parent node affected by the > batched events. The simplest way to batch events is to count the number > of mutation events and send DOMSubtreeModified after a given number have > been processed. More complex would be to add a timeout, to ensure the > SubtreeModified event gets flushed if insufficient modifications have > occurred to cause it to be emitted normally. >
I am now adding code to record the lowest common ancestor node, but after some consideration, I think both of the mentioned two ways to implement batch event have some problems. 1. If we count the number and send an event after a certain number. Given the number is 10, if there are 29 mutation events, we will send two DOMSubtreeModified events, but the last 9 mutation events will cause no DOMSubtreeModified event generated, and this will make the DOMSubtreeModified event unreliable. 2. If we use the timeout way. Then we need an asynchronous timeout event mechanism. Since libDOM is not thread-safe, we should never use thread-level timeout event. So, we should only use process-level timeout event, such as signal. And this pose a new constraint for the usage of libDOM: One process, one libDOM, one Document. I don't think this is a good constraint. So, I propose a new way to dispatch the DOMSubtreeModified event: 1. Dispatch one after each DOMCharacterDataModified 2. Dispatch one after an element's attribute changed. That is that dispatch one after a DOMNodeInserted(Removed) and a DOMAttrModified. 3. Dispatch one after bunch of DOMNodeInserted(Removed) and DOMNodeInsertedIntoDocument/DOMNodeRemovedFromDocument. That is that dispatch one after _dom_node_attach/_dom_node_dettach. That's all. Regards! Bo
