730771 - Make adding/removing a transform style not cause nsChangeHint_ReconstructFrame

Status: RESOLVED DUPLICATE of bug 691651

(Core :: CSS Parsing and Computation, defect)

Description

[Mats Palmgren (inactive)]

Looking at the remaining culprits (after bug 730769 / bug 728906) that makes
us slow on the IE Maze, it looks to me that they all come from a large number
of reflows.  This comes from the test toggling element.style.MozTransform
between "none" and "translate", so we hit:

http://mxr.mozilla.org/mozilla-central/source/layout/style/nsStyleStruct.cpp#2259
2259   /* If we've added or removed the transform property, we need to reconstruct the frame to add
2260    * or remove the view object, and also to handle abs-pos and fixed-pos containers.
2261    */
2262   if (HasTransform() != aOther.HasTransform()) {
2263     NS_UpdateHint(hint, nsChangeHint_ReconstructFrame);
2264   }

It seems to me that ReconstructFrame is overkill in this case, we could reparent views, 
abs/fixed pos descendants of the restyled frame, then reflow / recalculate overflow
areas as needed.

In the IE Maze case, I estimate that it will improve more than 60% if we can avoid
re-creating the frame for this style change.

Would this be possible?

Comment 1

[Timothy Nikkel (:tnikkel)]

We only have views on root frames, sub document frames, plugins and popups now, so they shouldn't cause any problems here.

We could also just bail out and reconstruct the frame if we have abs/fixed pos descendants.

Comment 2

[Mats Palmgren (inactive)]

My 60% estimate was accurate, I have a hack that now runs IE Maze at 41s. :-)
The top of the list is now:
3.7% nsAttrAndChildArray::IndexOfChild
3.6% nsDisplayBackground::GetBounds
3.0% ozone_size
2.7% PL_DHashTableOperate
... the remaining stuff is 2% or lower