I tried the timerslack tweaking workaround suggested in the earlier comments. Sadly, I saw barely any improvement: ~17 % with default timerslack vs ~15 % with 200000–1000000 ns, all on an Intel(R) Celeron(R) CPU G1610T @ 2.30GHz.
As part of my tests I wrote a small C program that applies a custom timerslack value to programs started through it. This may be useful for anyone who is seeing notable improvements with a tweaked timerslack value. The program requires neither root privileges nor manual intervention on server restarts.
Some additional information: after changing the path of the Java executable from the default to /usr/lib64/openjdk-8/bin/java, the game starts. I'm not sure why the launcher is resolving the target of /usr/bin/java (this is a symlink in Gentoo, and as the run-java-tool message in the launcher log says, not supposed to be resolved by programs using Java), nor why this doesn't fail under GNOME.
I'm pretty sure this is actually entirely unrelated to my window manager and a duplicate of MCL-12973. Not sure why switching window managers coincided with this bug appearing again.
I can reproduce the issue in 2.1.5411.
I tried the timerslack tweaking workaround suggested in the earlier comments. Sadly, I saw barely any improvement: ~17 % with default timerslack vs ~15 % with 200000–1000000 ns, all on an Intel(R) Celeron(R) CPU G1610T @ 2.30GHz.
As part of my tests I wrote a small C program that applies a custom timerslack value to programs started through it. This may be useful for anyone who is seeing notable improvements with a tweaked timerslack value. The program requires neither root privileges nor manual intervention on server restarts.
Usage instructions:
Some additional information: after changing the path of the Java executable from the default to /usr/lib64/openjdk-8/bin/java, the game starts. I'm not sure why the launcher is resolving the target of /usr/bin/java (this is a symlink in Gentoo, and as the run-java-tool message in the launcher log says, not supposed to be resolved by programs using Java), nor why this doesn't fail under GNOME.
I'm pretty sure this is actually entirely unrelated to my window manager and a duplicate of
MCL-12973. Not sure why switching window managers coincided with this bug appearing again.Sorry for the noise. Feel free to close this.