Also added a couple apzc tests. I'm also going to point the graphs page at mc vs inbound and clear the data file.

Hey Jim, are you taking this bug for IT#23? If so, can you provide a point value. Thanks.

Comment on attachment 8366152 [details] [diff] [review] patch Review of attachment 8366152 [details] [diff] [review]: ----------------------------------------------------------------- ::: browser/metro/base/tests/mochiperf/res/ripples.html @@ +230,5 @@ > progress = timestamp - start; > ripples.run(progress); > var time = new Date(); > var diff = time.getTime() - now.getTime(); > + if (diff < 5000) { // ten seconds nit: out of date comment ::: browser/metro/base/tests/mochitest/head.js @@ +223,5 @@ > +function hideNavBar() > +{ > + let promise = waitForEvent(Elements.navbar, "transitionend"); > + if (ContextUI.navbarVisible) { > + ContextUI.dismissNavbar(); "let promise = waitForEvent..." should be moved inside the "if" statement. @@ +226,5 @@ > + if (ContextUI.navbarVisible) { > + ContextUI.dismissNavbar(); > + return promise; > + } > +} In the case where the navbar is *not* visible, this should return an immediately-resolved promise instead of returning nothing (to prevent callers from failing unpredictably if they expect a promise). For example, you could add this at the end of the function: return Promise.resolve(null);

> "let promise = waitForEvent..." should be moved inside the "if" statement. > > @@ +226,5 @@ > > + if (ContextUI.navbarVisible) { > > + ContextUI.dismissNavbar(); > > + return promise; > > + } > > +} > > In the case where the navbar is *not* visible, this should return an > immediately-resolved promise instead of returning nothing (to prevent > callers from failing unpredictably if they expect a promise). For example, > you could add this at the end of the function: > > return Promise.resolve(null); Thanks. I updated both show and hide. Will push to try first.

Adding a couple tests and tweaking a few values. I also did some testing with these tweaking various apzc prefs, specifically the repaint_interval values. Generally I don't see a big difference there as long as the interval is within a band of values (25 -> 70 msec). So I don't think those prefs play much of a role in redraw performance. At least not on my surface pro.

https://tbpl.mozilla.org/?tree=Try&rev=7ba40832c61e https://hg.mozilla.org/integration/mozilla-inbound/rev/57b0e214f693

Landed on Aurora with Matt's blessing as a bustage fix for bug 913609. https://hg.mozilla.org/releases/mozilla-aurora/rev/0a8bb4f60f03

Could you please give some guidance in order for the QA to verify this? Thanks!

(In reply to Manuela Muntean [:Manuela] [QA] from comment #12) > Could you please give some guidance in order for the QA to verify this? > Thanks! nothing to verify here, these tests are working.

Thanks, Jim! Marking this [qa-].