This is a followup from bug 458878. We could do a bit more to coalesce changes when processing style changes. In particular: * when we're going to rebuild all style data, we don't need to process other style changes first, except to process their additional hints * when we also have a style change for an ancestor, we don't need to process a change on its descendant, except in so far as needed to process its hint. We could optimize only the rebuild-all case by pulling the hints out of a hash table while we're doing the rebuild, although the hash table lookups might cost much of the performance benefit. However, the general ancestor/descendant case is a little bit more work. I'm not sure whether this is worthwhile, though it may be worth investigating, especially if we find case where we're spending a lot of time processing style changes.

> * when we also have a style change for an ancestor, we don't need to process a > change on its descendant, except in so far as needed to process its hint. Bug 479655 made this happen. > * when we're going to rebuild all style data, we don't need to process other > style changes first, except to process their additional hints This was mostly done in bug 479655 for nsCSSFrameConstructor::RebuildAllStyleData, I think. eRestyle_LaterSiblings entries will still be left in the hashtable, given how we decided to handle it. But we could manually clear it after the rebuild, I'd think. Nothing changed for PostRebuildAllStyleDataEvent. Perhaps we should move that rebuild to the start of ProcessPendingRestyles? Should we call SetProcessingRestyles in RebuildAllStyleData, by the way?

I think bug 1115812 fixed most or all of what was left here.