X11 - Переадресація та ефективність

У мене є графічно інтенсивний додаток, який потрібно переслати на X11. Я витратив деякий час на дослідження X11 та його (не) ефективності, включаючи цей чудовий пост: Чому пересилання X11 настільки неефективне? .

Одне, що досі не є для мене чітко зрозумілим, чи залежить ефективність переадресації X11 від програми. У мене було враження, що весь екран передається вперед, незалежно від того, що відбувається. Тоді перенаправлення X11 повинно бути прикладним.

Отже, чи є якась конкретна інформація про те, що насправді передається та чи залежить продуктивність ssh -X від програми?

xorg remote-access x11-forwarding

— Фанг
джерело

"Отже, чи є якась конкретна інформація про те, що насправді передається та чи залежить продуктивність ssh -X від програми?" Так. Для початку дивіться розмову Даніела Стоуна «Справжня історія позаду Wayland та X» від LinuxConf.au 2013.

— sampablokuper

"У мене було враження, що весь екран пересилається" Важко зрозуміти, що справить на вас таке враження, адже те, що люди зазвичай роблять з переадресацією SSH X, - це вручну запускати окремі програми на віддаленій оболонці; Ви можете, можливо, детальніше розглянути, як запускаєте програми?

— rakslice

Один фактор зауваження, якщо ви транспортуєте сеанс X через тунель SSH: ssh може робити стиснення. Це -Cпараметр у командному рядку або Compression: yesпараметр у .ssh / config-файлі. Якщо ви робите традиційну X-переадресацію з Далласа в Австралію через перевантажене посилання T1, це може бути різницею між тим, щоб поставити перед вами завдання підняти діалог на п’ять рівнів в інтерфейсі і встановити прапорець від нереальної задачі до просто надзвичайно засмучує дві години. На щастя, у мене не було потреби спробувати це з Wayland, але я припускаю, що це значно покращилося.

— Ед Грімм

Я не хочу розпочинати широке обговорення в коментарях, тим більше, що на моє питання дуже добре відповіли @grawity. Під "на весь екран" я мав на увазі, що дані, передані через тунель ssh, завжди будуть простим описом пікселів на екрані. @ EdGrimm: Дякую за коментар щодо стиснення. Я про це знаю. У нашому конкретному сценарії X11 передається через 10Gbit LAN Link, а компресія / без стиснення, здається, абсолютно не має різниці.

— Fang

У мене було враження, що весь екран передається вперед, незалежно від того, що відбувається. Тоді перенаправлення X11 повинно бути прикладним.

Ні, насправді навпаки. Причина переадресації X11 називається "перенаправлення X11" в тому, що вона переносить фактичні повідомлення протоколу X, які використовуються програмами для візуалізації своїх вікон на "X-сервер" (зазвичай Xorg). Ці повідомлення - це команди для створення / переміщення вікон, малювання тексту та графічних примітивів (ліній / прямокутників), малювання растрових зображень тощо.

Можна сказати, що це концептуально протилежна протоколам "повноекранного зображення", таких як VNC / RFB. Я думаю, що це дещо порівняно з RDP Windows, який також був створений для транспортування команд малювання GDI.

Тож причини, по яких ви бачите відмінності між програмами:

Щоб цитувати публікацію, на яку ви посилалися, спочатку більшість програм на базі X працювали так:

В основному X11 не надсилає екран на ваш комп'ютер, але він надсилає інструкції до дисплея, щоб X-сервер на вашому локальному комп'ютері міг створити екран у вашій локальній системі.

Тож коли програма хотіла показати кнопку, вона просто надіслала кілька коротких команд - "намалювати прямокутник", "намалювати текст" і, можливо, деякі рядки, щоб він виглядав 3D.
З часом це змінилося, програми почали робити рендерінг самостійно, і багато з цих інструкцій стали просто "ось растровий малюнок, який я вже надав, виставив це на екран" - дуже швидко локально, але дуже повільно по мережі через відсутність X11 стиснення зображення

Це означає, що програми, побудовані за допомогою сучасних наборів інструментів, значно повільніші за мережевий X11, навіть якщо це щось таке ж базове, як антиалійні шрифти.

(На відміну від цього, RDP з часом адаптувався і включає різні форми стиснення зображень, такі як JPEG і навіть H.264; ви часто можете помітити артефакти стиснення, коли завантажується повне зображення.)
На щастя, більшість наборів інструментів користувальницького інтерфейсу, таких як GTK, реалізують відстеження шкоди, тому повторно надсилаються лише оновлені регіони. Однак декілька програм (наприклад, декілька версій Firefox / Thunderbird) не підтримують це і вимагають повного повторного відображення всього вікна, навіть якщо воно дійсно не оновлено.

Це ще одна відмінність програм - добре сприятливі програми все ще досить зручні в мережі, але баггі можуть наситити 100 Мбіт / с, не роблячи абсолютно нічого корисного.

— зернистість
джерело

Я пам’ятаю, як одного разу намагався налаштувати сервер MythTV. Утиліта "setup" була додатком Qt і займала кілька хвилин для відображення кожної сторінки конфігурації, незважаючи на розумне посилання ADSL як вузьке місце (майже 8 Мб / с). Через це пішло декілька хвилин роботи - через інтерфейс Curses або навіть добре сприйняту програму X11 було б набагато простіше. Якби я знав, з якою проблемою це буде, я б зачекав тиждень-два, поки я не виявився на місці, і використав би одну з бездискових фронтальних коробок для показу. Хоча я хотів, щоб сервер працював і працював раніше, ніж це.

— Toby Speight

На захист цих "програм-баггі" слід зазначити, що в цьому винна ідеологія інструментарію X +, яка, в основному, зумовлює необхідність тих програм, що займаються баггі, в першу чергу. Ви б могли подумати, що програма може просто викликати API (який надсилає команду), щоб мати "вікно звичайного вигляду", меню і кнопку тут, а також смугу прокрутки, але ні. Ви або інструментарій повинні робити все вручну. Я насправді не великий фанат MS, а тим більше Apple, але вони все зрозуміли , тоді як екосистема X смоктала десятиліттями і досі смокче.

— Деймон

Я не впевнений, чи є різниця. Що робить UWP або WinForms або comctl32 для Windows менше "набору інструментів", ніж GTK та QT? Хіба вони також не роблять все "вручну"?

— grawity