1164643 - 12.4% win8 tresize regression on aurora uplift

Status: RESOLVED WONTFIX

(Testing :: Talos, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

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.

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

Mason, you might have more of a backstory on the vsync stuff.  It could be that this win/regression is unrelated- any thoughts?

Comment 2

[Mason Chang [Inactive] [:mchang]]

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 [1] all to true.

https://dxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js#4718