Some talos profiling has discovered that glXWaitGL is blocking for far longer than it should [1]. According to a KWin bug, glXWaitGL waits until the next VBlank on NVIDIA [2]. Considering that we don't require X and GL rendering synchronization since we no longer use XRender, we should remove this call. [1] https://treeherder.mozilla.org/perf.html#/compare?originalProject=fx-team&originalRevision=3b7148db9a79&newProject=try&newRevision=0731b6a5d38a&framework=1&showOnlyImportant=0 [2] https://bugs.kde.org/show_bug.cgi?id=303397

Comment on attachment 8784159 [details] Bug 1297537 - Avoid calling glXWaitGL in GLContextGLX::SwapBuffers. https://reviewboard.mozilla.org/r/73710/#review71576

Pushed by acomminos@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/dfb4628966be Avoid calling glXWaitGL in GLContextGLX::SwapBuffers. r=jgilbert

== Change summary for alert #2690 (as of August 23 2016 23:36 UTC) == Summary of tests that regressed: ts_paint linux64 opt: 1374.62 -> 1545.17 (12.41% worse) Summary of tests that improved: tpaint linux64 opt: 331.57 -> 301.63 (9.03% better) tresize linux64 opt: 41.15 -> 32.88 (20.08% better) For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=2690

as a note, tp5o is added to the list. tpaint and tresize are about halfway fixed, tp5o seems to be fixed completely. odd that ts_paint is worse.

is there any reason why this would not be showing up on Aurora? As it stands we have improvements on trunk and during the merge of 51 to Aurora we do not see these improvements. I couldn't see any config issues related to the specific line or file that was edited, maybe there is a larger config issue for GL to be on trunk only.