This is probably related to bug #1038800 and similar. Encountered this game off of a link on Hacker News, checked it out. Firefox almost totally froze up, sucking up a couple of cores. Loaded chromium, worked fine. Created a new profile, set azure to skia, and Firefox rendered fine.. Going to guess this is a case of Linux/Firefox testing getting skipped again. Of course, skia has pages where the exact opposite is true, like my experiment with a similarish animation on http://m8y.org/tmp/testcase429.xhtml which uses 200% CPU in chromium and has bad rendering as well. My solution is to usually just use skia for canvas and cairo for content. Upshot is that it's hard to pick a value for azure that works all the time, unlike the situation on Windows where Firefox seems extremely well behaved compared to Chrome in terms of rendering.

Oh, just realised I didn't describe the incorrect rendering. There's a CSS animation that moves a wavy pattern across the sky to make the stars "twinkle" With cairo, this pattern is visible over the planet as well (and overall performance is horrible). With skia it is not.

Initial investigation seems that almost all of the compositor time is being chewed up in a 3D transform, which the basic compositor is not going to accelerate at all. It's not so much that Cairo or Skia is at fault here, it is that xrender is used for compositing by default, so if you have a 3D transform, it's going to have to read back from the X surface, do the transform, then send it back over to the X server, and this is going to churn, churn, churn. I'm not sure there is much that can be done here besides use the OpenGL compositor or disable xrender.

Huh. So why do I see the wavy pattern over the planet with cairo, but not with skia? And why did the page seem sluggishly unusable w/ 2 of my cores maxed out only w/ cairo, if it has nothing to do with those 2? Skia doesn't use xrender?

By coincidence I ran into this testcase here again. I noticed that we can actually push this back onto the 2D path by being a bit more careful in some of our layers code that computes effective transforms. The particular CSS transforms used on robogem were ending up with a matrix that was only a 2D scale/translation matrix but for some W coordinate scaling that could be easily normalized out. With this patch I'm not hitting the 3D transform path in BasicCompositor anymore on that site.

Comment on attachment 8728781 [details] [diff] [review] make Matrix4x4::ProjectTo2D normalize out perpective where possible Review of attachment 8728781 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/2d/Matrix.h @@ +547,5 @@ > _23 = 0.0f; > _33 = 1.0f; > _43 = 0.0f; > _34 = 0.0f; > + // Normalize out perspective to convert to a 2D matrix where possible. A more detailed comment about how 0,0,N in the 4th column only has the effect of scaling the output, so we can normalize it and just scale the matrix instead would be good :)

(In reply to Matt Woodrow (:mattwoodrow) from comment #5) > Comment on attachment 8728781 [details] [diff] [review] > make Matrix4x4::ProjectTo2D normalize out perpective where possible > > Review of attachment 8728781 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: gfx/2d/Matrix.h > @@ +547,5 @@ > > _23 = 0.0f; > > _33 = 1.0f; > > _43 = 0.0f; > > _34 = 0.0f; > > + // Normalize out perspective to convert to a 2D matrix where possible. > > A more detailed comment about how 0,0,N in the 4th column only has the > effect of scaling the output, so we can normalize it and just scale the > matrix instead would be good :) Will do.

Try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=641ebea5822a