STR: http://mrdoob.com/lab/javascript/threejs/css3d/periodictable/ Run fast on on chrome. Performance profile: http://people.mozilla.com/~bgirard/cleopatra/?report=85e0f281078aab53f0b20988c2cd6400b1ff37a7

Flush styles takes about 250ms a frame and then the paints are about 350ms.

Pretty sure this is safe, and reduces some of the unnecessary painting. Looks like the biggest chunk of time is being spent in ComputePreserve3DChildrenOverflow (~60%), most of which is in GetResultingTransformMatrix.

Removed accidental printf code.

Comment on attachment 676016 [details] [diff] [review] Don't invalidate when the overflow changes v2 Review of attachment 676016 [details] [diff] [review]: ----------------------------------------------------------------- Eep, I forgot we still had this. Removing this block means you can simplify the code further. Get rid of hasClipPropClip, didHaveClipPropClip, hasOutlineOrEffects and preTransformVisualOverflowChanged.

Not really a big performance issue, but this bug meant that we overwrote the initial overflow with the transformed one. Was causing us to allocate much larger layers than we needed.

This is a huge performance gain in this demo, ComputePreserve3DChildrenOverflow was more than 50% of the profile.

Previously we would flush the temporary list (and wrap them in an nsDisplayTransform) when we encountered an nsDisplayWrap list. In the case where we had multiple nsDisplayWrapLists, we'd end up with multiple nsDisplayTransforms. This changes the behaviour so we walk through nsDisplayWrapList, it's about a 2/3 reduction in the number of nsDisplayTransform/ContainerLayers created in this demo. I think there are still bugs here.

This is no longer useful for this demo, since the previous patches stop us from recomputing so many transforms. For the record, the basic problem with the demo was that it had a single preserve-3d parent with a few hundred transformed children. Each frame of the animation changes the transform on each child. For each child transform change, we walk up the ancestor tree calling UpdateOverflow(), and this hits ComputePreserve3DChildrenOverflow, which computes the transform for all the children. O(n^2) behaviour is not fun. This patch might be useful for other cases where we do end up computing transforms too often, but I don't want to add this complexity unnecessarily.

As above, no longer useful on this demo. Might be useful if we find a use-case that is changing the size of the preserve-3d parent frame, but the transform doesn't actually depend on the size.

Note that we still have the issue that changing the overflow of multiple children results in us calling UpdateOverflow() on the common ancestors multiple times. Much less of an issue now that the O(n^2) path is gone, but it might be nice if we could coalesce these.

Editing the bug title slightly so that searching for 'periodic table' gets this.

https://hg.mozilla.org/integration/mozilla-inbound/rev/af535a8e7f6e https://hg.mozilla.org/integration/mozilla-inbound/rev/374270441a49 https://hg.mozilla.org/integration/mozilla-inbound/rev/08d397c13da6 https://hg.mozilla.org/integration/mozilla-inbound/rev/01123067aa58

without this fix windows 8 require actual reboot after opening this page, would make sense to increase priority

https://hg.mozilla.org/mozilla-central/rev/af535a8e7f6e https://hg.mozilla.org/mozilla-central/rev/374270441a49 https://hg.mozilla.org/mozilla-central/rev/08d397c13da6 https://hg.mozilla.org/mozilla-central/rev/01123067aa58

Verified on 2012-11-04)

Here's a profile of what I get with these patches. It's running well with OGL but not well with Basic: http://people.mozilla.com/~bgirard/cleopatra/#report=f63355043dd883c2243f5a06a7359fc797f7be3e New bug to track further work needed: bug 808838

Backed out from beta: https://hg.mozilla.org/releases/mozilla-beta/rev/dc5dec1293ab

I confirm fix is verified on FF 19b4 and Aurora Latest (2013-01-30) on Mac OS 10.8 x64. Dependency chain with: Bug 807563 and Bug 815666.