Australis performance report #4

Mike Conley mconley at mozilla.com
Mon Nov 4 13:15:24 PST 2013


Hey firefox-dev,

Boy, I've been waiting to write this email for a while.

TL;DR: the OS X TART blocker has been cleared. We are no longer blocked 
on landing from TART performance regressions. We have an OS X crasher 
bug that we're investigating though[2].

Details:

This whole week, I've been working with Jeff Muizelaar from the graphics 
team on our last TART blocker bug, which is bug 924415[1].

Here's what we found out:

When we draw in the titlebar, and that drawing overlaps the titlebar of 
another window from the same process, the OS X WindowServer spends a lot 
of time inside of a function called affineGLAccel while it is 
compositing. When the window does not overlap the titlebar of the other 
window, these affineGLAccel calls (and the regression) go away.

Talos opens a "pageloader" window, which sits in the background during 
the TART tests. This is the window we're overlapping with, and this is 
what's causing our regression.

We were able to show this by modifying the TART test to move the browser 
down 22px (the height of the OS X titlebar) before running the test. 
That meant that the Firefox window was not overlapping the titlebar of 
the pageloader window, and the regression went away.

Also note that this weird behaviour from WindowServer does not affect 
overlapping of windows from other processes.

What's more, this WindowServer business isn't restricted to Firefox. 
Other applications that draw in the titlebar suffer from it as well. 
Safari hits it particularly hard - according to Jeff, Safari seems to 
hit the slow patch _every time_ it draws anything. So we're actually in 
a better position than them.

Jeff has also pointed out that attempting to trick the WindowServer or 
otherwise workaround this problem is likely far more work than it's 
worth. We could probably do other things that would buy back this 
regression across the board, and that'd be a far better use of our time.

So, after talking it over with Dolske and Jeff, we've determined that:

(1) The severity of the regression (pretty low), (2) the difficulty of 
the fix / workaround (very high), and (3) what's needed to actually 
trigger it, all comes together to look like a WONTFIX. At the very 
least, it's no longer a landing blocker.

So that's that. I've removed the landing blocker status. We no longer 
have any performance related landing blockers.

But don't crack out the champagne yet - an OS X crasher showed up on 
Friday[2], and we have to fix that before we can land. Rest assured, 
we're on it. With gusto.

So bug 924415 is a textbook example of cross-team cooperation. It was 
4th-quarter-Mighty-Ducks teamwork, and it was awesome. A big thanks to 
Jeff and the rest of the Graphics team for their help on it!

Unless something new performance-wise shows up (please no), I'll 
probably not be writing another one of these updates to firefox-dev. 
Instead, I'll be writing some blog posts[3] after all of the dust 
settles about this performance work, and give a full breakdown of what 
happened, why, and what we learned along the way. Stay tuned for that.

EAT IT TART, YOUR TEARS ARE DELICIOUS,

-Mike

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=924415
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=933964
[3]: http://mikeconley.ca/blog/category/mozilla-2/, which feeds into planet.


More information about the firefox-dev mailing list