Australis performance report #4
mconley at mozilla.com
Mon Nov 4 13:15:24 PST 2013
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.
This whole week, I've been working with Jeff Muizelaar from the graphics
team on our last TART blocker bug, which is bug 924415.
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, 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 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,
: http://mikeconley.ca/blog/category/mozilla-2/, which feeds into planet.
More information about the firefox-dev