Icons do not have transparent background / slow performance over remote X11 server connections

It was observed by our Linux users that the recent versions of IDEs became slow and even froze for several seconds when working over a remote X server connection (either directly or via ssh tunneling regardless of the X server used). The slowness can primarily be attributed to images round-trips between the X client and the remote server. The latest improvements of the UI triggered these previously unused X11 protocol features. The effect on the performance is negligible for a local X server that communicates with the client through memory, but for a remote one - even if it's physically not very remote - the difference in timings starts at 20x.

The version of Java Runtime Environment bundled with IntelliJ products - JetBrains Runtime - implements a workaround for such "slow" (footnote: everyone's pain threshold is different and the perceived slowness may differ from the measured one) remote X connections. This workaround almost eliminates images round-trips between the X client and the remote X server and greatly improves IDE responsiveness. This was done at the expense of disabling alpha compositing of images (footnote: this is when a semi-transparent image is drawn on top of another image; shadows are typically implemented this way). The downside is that internal small window shadows and icons backgrounds aren't nice anymore and appear as one-color borders of various thickness.

The feature activates itself when all these conditions are met

• a remote X11 session has been detected,
• the workaround was not disabled explicitly through the -Dremote.x11.workaround option,
• a potentially slow operation is used,
• that operation took > 20 milliseconds to complete (usually the time is close to 1ms or below for a local X11 session).

In this event, this message will be printed to the standard error stream:

[JetBrains Runtime] Detected slow X11, switched off alpha compositing of images. Control with -Dremote.x11.workaround={true|false|auto}.

To control the workaround with the VM option, go to Help | Edit Custom VM Options... and paste

-Dremote.x11.workaround=false

at the end of the opened file. The default value for the option is "auto" and there should be no reason (other than for testing purposes) to set it to true because if auto didn't turn the workaround on, you will not see any improvements by forcing it.

Adding -Dremote.x11.workaround=false should remove any effects of the workaround, including the message printed to the terminal. If you still see the message after adding the option, please check that the option was actually passed down to the underlying Java process (there are several ways to specify vmoptions). You can run jps -mv (this one is specifically for Java, but any other way of finding executing process' arguments will do such as ps -f) on the system where the IDE is started and check for the presence of -Dremote.x11.workaround=false among the arguments. Here's an example of what you might see (output formatted for clarity):

5779 Main -Xms128m -Xmx991m -XX:ReservedCodeCacheSize=512m -XX:+UseG1GC -XX:SoftRefLRUPolicyMSPerMB=50 -XX:CICompilerCount=2
...
-Dremote.x11.workaround=false
-XX:ErrorFile=/home/maxim/java_error_in_idea_%p.log
-XX:HeapDumpPath=/home/maxim/java_error_in_idea_.hprof -Didea.vendor.name=JetBrains -Didea.paths.selector=IntelliJIdea2021.1
-Djb.vmOptionsFile=/home/maxim/.local/share/JetBrains/Toolbox/apps/IDEA-U/ch-0/211.7628.21.vmoptions

With this option properly spelled, icons and shadows appear normal and there's no message about the workaround on stderr.

You can upvote this feature IDEA-272179 (Provide simplified UI for slow X11 connections) if the workaround is a necessity for you and the associated UI artifacts are a bother.

There are alternative solutions that are readily available. Any other technology to translate a graphical user interface over the network that isn't reliant on the X11 protocol should not suffer any slowdown from this issue: VNC, RDP, Projector, etc. With Wayland coming to our desktops, one of those solutions will have to be used for remote work in the not so distant future.