mozregression pointed me to bug 1241832. Interestingly, this isn't happening in my Firefox profile, but is happening in a clean profile (probably because AdBlock is blocking some elements, e.g. the Facebook widget).

The profile from comment 3 is taken from a *bad* build, this is from a *good* one: https://cleopatra.io/#report=b5aac709d01c55e3efe9cf2d6e27fb35173e7bf4

This is the about:support from the *good* build (the other one was from the *bad* one).

Looks like this is from turning off XRender. The "after" profile isn't using XRender, and the compositor is spending 95% of its time in |CompositorParent::Composite|, 80% of which is in |_moz_pixman_image_composite|. The "before" has XRender on and |CompositorParent::Composite| barely shows up on the profile. ni?lee to confirm, and because he loves XRender sadness.

This will likely get faster after bug 1255281 (probably still not as fast as it was, though...).

(In reply to Edwin Flores [:eflores] [:edwin] from comment #8) > This will likely get faster after bug 1255281 (probably still not as fast as > it was, though...). Confirmed. We were falling off the fast path in pixman again. The added BGRX->BGRA fast-path is where we spend most of our time now. Not sure if it made it's way into nightlies yet, but pulling from central and building that way at least should have it in. I'm not sure there's more that we can do for this case than that, though.

Yeah, it doesn't seem to have helped much.

If we don't manage to figure this one out, chances are we will just live with it, not having xrender is that important. Parking with me until we sort this out.

We're going to stick with not having xrender.