Проблема с пересылкой современный X (не который "старый" X, когда была изобретена его сетевая прозрачность) со сглаживанием шрифтов: для правильного сглаживания каждый глиф текста, отображаемого на некоторой поверхности, X-сервер должен получить растровое изображение, которое находится под ограничивающей рамкой этого глифа, от клиента, который желает отобразить этот глиф. (Это необходимо для правильной работы алгоритма сглаживания, поскольку он учитывает контекст, в котором глиф отображается.)

Следовательно, с современными инструментами графического интерфейса пользователя объем трафика между X-сервером и его клиентами составляет огромный: вы можете увидеть это, включив TCP на локальном X-сервере (в наши дни они обычно запускаются с -nolisten tcp) и заставьте X-клиент на основе GTK или Qt разговаривать с сервером через TCP:

$ DISPLAY=localhost:x11 /usr/bin/that/x-app

(видеть grep x11 </etc/services для стандартных портов X-сервера). Вы сразу заметите, насколько медленно ведет себя этот клиент, даже если X-трафик не покидает локальный хост: это просто потому, что обычно X-трафик передается через сокет Unix-домена, который в основном просто копирует байты между буферами в памяти, таким образом имея довольно низкий накладные расходы, и теперь он проходит через полный стек TCP / IP со всеми его очередями и сложной логикой. Теперь подумайте, что происходит, когда этот трафик отправляется в вашем случае - обернутый в три уровня протоколов передачи данных: туннель SSH, переносимый туннелем VPN, переносимый TCP / IP по проводам.

Что с этим делать, я не уверен.

С участием mosh быть вне игры, Я бы попробовал поиграть с IPQoS вариант клиента OpenSSH.

Другой подход - обратиться к проблеме с другой стороны: попробуйте доступ к вашему приложению на основе VNC. Здесь разные варианты:

• Вы можете начать просто с экспорта всего дисплея через x11nvc или что-то вроде этого.
• Используйте программные пакеты, которые могут «экспортировать» конкретное приложение или окно -Xpra и winswitch.
• Попробуйте более тяжелое, но полное решение, такое как X2Go.

Я столкнулся с проблемой, которая действительно похожа на вашу: некоторые приложения gtk (например, meld) медленно запускаются через ssh, а некоторые нет (например, синаптические). На самом деле я могу быть более точным, насколько он медленный:

$ echo "$TIMEFORMAT"
        %R
$ time meld --version
meld 3.20.0
        25.293

Это то же самое время, что и в других медленных приложениях, которые я нашел (nemo, gedit).

При проверке слияния с strace выясняется, что он ожидает какого-то события, которое никогда не наступит и существует с таймаутом ровно 25 секунд.

Очень вероятно, что эта проблема аналогична той, о которой сообщалось здесь: https://bbs.archlinux.org/viewtopic.php?id=230036

Это проблема dbus - среда сеанса, которая не настроена по ssh. К сожалению, я не знаю, как это исправить.

Единственный обходной путь, который я нашел с meld, - это запустить его в фоновом режиме, прежде чем я смогу использовать его обычным способом.

редактировать

Нашел! Просто запустите dbus и экспортируйте сообщаемые переменные:

$ dbus-launch 
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-2EzslkNeji,guid=c9dec1622d6575f468559f8b5d9ee0e0
DBUS_SESSION_BUS_PID=4745

Установите указанное выше и экспортируйте, затем:

$ time meld --version
meld 3.20.0
        0.268

Я помещу это в свой сценарий запуска на удаленном компьютере и сообщу здесь.

Следовать за

Это довольно многословно и в значительной степени выходит за рамки, но поскольку мне нравятся простые в использовании решения для копирования / вставки в сообщениях, которые я вижу, я могу за исключением того, что вы тоже. Я протестировал следующее в качестве сценария сеанса для подачи ssh (например, ssh -X my @ dark-side ~ / bin / session):

#!/bin/bash

LAUNCH=(
    #   xload
    #   thunderbird
      dbus
      konsole
)

Tmp=$(mktemp -d)
mkdir -p $Tmp

KILLS=()
WAITS=()

echo "info: starting session" >&2

app_dbus() { # # Launch dbus and remember to kill
  # redirect error because of "create ~/.dbus/session-bus/" 
  # deal with failure by checking DBUS_SESSION_BUS_PID afterwards
  dbus-launch > $Tmp/dbus.sh 2>/dev/null
  . $Tmp/dbus.sh

  if [ "$DBUS_SESSION_BUS_PID" ] && 
       ps --no-header -o pid -p "$DBUS_SESSION_BUS_PID" \
          > /dev/null 2>&1
  then
    export DBUS_SESSION_BUS_ADDRESS DBUS_SESSION_BUS_PID
    KILLS+=( $DBUS_SESSION_BUS_PID )
  else
    echo "warning: failed dbus" >&2
  fi
}
app_konsole() { # # Launch konsole and remember to wait for
  konsole &
  WAITS+=( $! )
}

for APP in "${LAUNCH[@]}"
do
  app_$APP
done

rm -r $Tmp  # not needed anymore

wait "${WAITS[@]}"

echo "info: ending session" >&2

for ID in "${KILLS[@]}"
do
  kill $ID
done