http://graphs.mozilla.org/graph.html#tests=[[254,52,31],[254,64,31],[254,63,31]]&sel=1423771535559,1431547535559&displayrange=90&datatype=geo this is a case where we have a win on aurora which upon uplift was lost. On April 6th we see a win on Aurora for this given range: http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=e8ed559c3ebe&tochange=28e3d5964195 Unfortunately that is a lot of changes. I see: * Mason Chang — Bug 1150223 - Disable vsync compositor on Windows on Gecko 39. r=kats, a=lizzard * reading list stuff (although we were adding it at this time) * packaging code / test code * some skia changes Most likely this is related to the vsync stuff. I am not clear why this is disabled on 39 and not on 40.
Mason, you might have more of a backstory on the vsync stuff. It could be that this win/regression is unrelated- any thoughts?
Hmm, not sure why it's a regression. From the original landing, it doesn't look like any tresize regressions - https://bugzilla.mozilla.org/show_bug.cgi?id=1144451#c2. But from talos try, it caused only a 5% tresize regression. The vsync work is disabled on Gecko 39 on Windows explicitly to minimize graphics risks in Gecko 39. We chose to explicitly only enable it from Gecko 40 and onwards. Maybe you can try to see if enabling the vsync compositor brings the performance back? You can set the prefs at  all to true. https://dxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js#4718