Протокол удалённого рабочего стола

Может я и ошибаюсь, но X-протокол это и есть до некоторой степени команды отрисовки. И проблема не в X-протоколе, а в том, что GTK и KDE не эффективно его используют с точки зрения передачи по сети. И есть NX NoMachine, который «фильтрует/сжимает» X-протокол, чтобы эффективно передавать поток от графических тулкитов.

Есть ли смысл что-то подобное пилить?

Конечно. Напилитесь вдоль и поперёк, узнаете много нового.

Так я про Wayland в первую очередь. А иксовый тулкит непригоден для отрисовки современных приложений, вот тулкиты и рисуют всё сами под иксами, а потом гоняют битмапы туда-сюда.

qt либо напрямую через gl рисует, либо софтварно рендерит в локальный буфер и шлёт на экран целиком.

По-моему - не особо: через тот же Parsec что работать, что игрульки играть можно совершенно беспроблемно, даже через HSDPA+. А он тупо гоняет видео всего десктопа. Поэтому считаю, что лучше создавать ему (и подобным решениям) свободную замену, а то наплодили для удаленного запуска игрулек -надцать «свободных» программ, гвоздями прибитых к невидии.

Поэтому считаю, что лучше создавать ему (и подобным решениям) свободную замену

Rustdesk. Но там проприетарный тулкит используется.

А он тупо гоняет видео всего десктопа

Без плагинов будет то же самое гоняние видео. Но ведь с плагинами же эффективнее. Плюс можно OpenGL на стороне клиента отрисовывать, когда на сервере вообще видеокарты нет. Да и управление сессиями реализовывать нужно ещё, чтобы как в RDP было.

Без плагинов будет то же самое гоняние видео. Но ведь с плагинами же эффективнее.

Если звезды не зажигают - значит, не нужно.

Плюс можно OpenGL на стороне клиента отрисовывать, когда на сервере вообще видеокарты нет.

Обычно баланс мощностей обратный - слабенькое устройство подключается к мощному.

Да и управление сессиями реализовывать нужно ещё, чтобы как в RDP было.

И это не особо нужно, уже лет десять как проще создать по виртуалке на терминал, чем жонглировать сессиями.

Для тулкитов пишутся плагины…

у gtk это бэкэнд называется. в gtk4 бэкэнд использует html css и js

пример https://people.gnome.org/~alexl/broadway-gtk4.html

Ну, в Qt тоже подобное есть. Только нужно сделать, чтобы уже запущенные в Wayland-сессии приложения отрисовывали и локально, и команды отсылали.

Есть ли смысл что-то подобное пилить?

В общих чертах это называется сетевая прозрачность в X11 протоколе и было реализовано в конце 80тых (правда там помощнее всё былО - с поддержкой фонтов, принтеров и прочей периферии на клиенте). Конечно, для вяленого надо написать что-то похожее! :D :D :D :D

в X11 протоколе и было реализовано в конце 80тых

Примерно тогда, наверное, оно последний раз нормально и работало.

Примерно тогда, наверное, оно последний раз нормально и работало.

в 2008 годы я этим пользовался под чпуксом.

в 2005 годы настраивал сервер фонтов и печати и даже печатал just for fan. Потом это поломали и выпилили ибо якобы «ненужно».

Сетевая прозрачность в openmotif и сейчас, наверно, заработает без особых проблем. Но ты пили - «новое - это хорошо забытое старое» не сегодня и даже не вчера придумали.

Если приложение/тулкит всё сам рисует (а именно так они сейчас и делают), то проще сразу видео по сети посылать, как в VNC.

Если приложение/тулкит всё сам рисует (а именно так они сейчас и делают), то проще сразу видео по сети посылать, как в VNC.

Ты уж определить, что тебе надо - «проще», «лучше» или «правильнее». vnc шлёт jpg, а не видео. «они сейчас и делают» - кто они? 95% людей используют rdp под виндой, который шлёт примитивы :-)

скажем так: жена, которая работает под rdp, прекрасно работает на практически любых каналах из любых ебеней, в отличии от меня, сидящего под vnc.

Так как в Linux нет снизу такой штуки, как WinAPI, сделать подобное будет очень сложно. К тому же из-за той же конкуренции Qt и GTK+ писать и отлаживать нужно будет в два раза больше.

Именно поэтому все и гоняют битмапы. И как по мне правильно делают. Это банально проще и за этим будущее. Графика и интерфейсы усложняется и уже не влазит в те примитивы, которые можно представить в рамках сетевой прозрачности. Если хочется улучшить ситуацию, то вкладываться (трудом) наверное нужно в быстрое сжатие/распаковку битмапов и алгоритмы более умного распознования изменений на окне/экране.

Получить какой-то небольшой прирост по скорости за счёт отправки «векторных» команд в эпоху когда у каждого на смартфоне 5G с > 200 Mбит/с? Наверное стоит потратить свой энтузиазм на что-то другое.

И кстати, а насколько этот RDP передаёт именно команды отрисовки тулкита, может кто в теме по техническим деталям? На сайте MS нашёл какие-то спеки под 500 страниц каждая, лень в это всё вникать и разбираться когда знающие люди есть на ЛОРе. Вот запускаю я, например, какое-нибудь приложение на Electron или клиент Telegram Desktop на Qt и шлю картинку по RDP. И чего? Мне на хост прилетят те команды GDI, которыми была отрисована картинка в Telegram Desktop на удалённой тачке? Так это невозможно. Тот же Qt рисует самостоятельно, а GDI отдаёт лишь битмап, насколько я помню. Или же RDP это такой «умный» VNC, который на лету анализирует битмап окна (того же Telegram, к примеру), видит на нём линию/прямоугольник и посылает мне на хост действительно через GDI мол нарисуй по таким-то координатам с таким-то цветом. А остальное, что не смог векторизовать, шлёт битмапом? Или же там действительно сетевая прозрачность для простеньких WinAPI-приложений будет работать?

кто они?

Они — тулкиты.

скажем так: жена, которая работает под rdp, прекрасно работает на практически любых каналах, в отличии от меня, сидящего под vnc.

Так в иксах будет точно так же тормозить, как в VNC.

Так в иксах будет точно так же тормозить, как в VNC.

?? Motif с сетевой прозрачностью прекрасно работал на доисторических каналах.

Ну, для начала можно просто базовую версию сделать, в которой как раз и будет по сети передаваться какой-нибудь AV1/VP9. Ещё virtualgl нужно, чтобы можно было на клиенте отрисовывать, когда на сервере видеокарты нет.

А потом уже можно пытаться тулкиты патчить, чтобы они одновременно и через Wayland рендерили, и команды отрисовки через Web-бэкенд посылали (который там уже и так есть).

Потому что использовал Xlib.

Есть ли смысл что-то подобное пилить?

Конечно есть
На дворе 2021 год, а в линуксе до сих пор нет быстрого графического клиента

Именно поэтому все и гоняют битмапы.

С точки зрения EXL — безусловно. А вообще, это совершенно не так. По крайней мере, в таком хорошо спроектированном продукте, как X'ы.

По крайней мере, в таком хорошо спроектированном продукте, как X’ы.

И что же такой хорошо спроектированный «продукт» как X11, сегодня гоняет битмапы ещё хуже, чем VNC?

Это идиотия и браться за это не надо.

За что надо взяться, это за rendering библиотеку либо Wayland, либо только GTK/Qt/EFL/SDL и т.д. Что-то а-ля Win32/GDI, поверх которого в Windows работают классические приложения. Причём ограничиваться рисованием мало - оно должно уметь рендерить шрифты, учитывая kerning, направление написания, ротацию, gamma и прочее. Всё это как-то надо впихнуть в протокол рисования. Плюс, оно должно уметь задействовать всякие аппаратные фичи ускорения 2D графики - без понятия как это работает под KMS/Wayland Compositor.

А потом вы будете отчаянно пытаться уломать разрабов всех этих библ принять ваши патчи, а они откажут, ибо «не мы написали».

Я бы забил нарочь - это чудовищный объём работы.

// b.

Затея на миллион, честно говоря. Я бы пошёл в RedHat и нанялся с этой задачей.

Если реализуете - это будет КЛАССНО.

Остаётся только:

https://gitlab.freedesktop.org/wayland/wayland/-/issues/233

Есть примерно такое (https://github.com/loki-47-6F-64/sunshine). Nvidia gamestream для всех. Умеет в win/linux (кто-то даже для macos попытался портировать), Radeon/geforce

смотрел freerdp, передают также pixmap в основном, если кто и шлет команды то только винда мб, там у них из нового это типа RemoteFxCodec и NSCodec.

из стандартного xorg в rdp можно отправить так же только pixmap, который через damage notify только и ловить, поэтому там проект xrdp этот xorg и пилят вроде.

проблема в vnc неоптимальный encoding, либо многоядерность не используется. либо это в коммерческую ветку завернуто. там где я тестировал было нормально.

Да, пили. Только без фанатизма.

реализовано

Почему так сильно лагает RDP на linux? (комментарий)

Нет. Есть две жизнеспособные крайности удалённой отрисовки приложений — гнать видеопоток без выпендрежа и Web 2.0, обе уже изобретены.

обе уже изобретены

Так предложение состоит в том, чтобы их скрестить. Протокол удалённого рабочего стола (комментарий)

Здесь должна была быть ссылка на цитату про два метра колючей проволоки, но квотезы закрыты, поэтому вместо нее будет «поздравляю, ты изобрёл ютуб».

При чём тут ютуб?

Потому что только для встраивания видео в страницу твоя идея и годна.

На SPICE можешь посмотреть, он умеет встраивать в общий lossless как у VNC видеопоток прямоугольник ом. В эпоху 4K работает ни рыба, ни мясо, проще все гнать как видео.

То, что объём работы большой, — это понятно. Но ведь векторные команды должны быть легче видеопотока.

(напомнило [в моем мире] скринкаст весит <100КБ)

Угу, а необходимость вкручивать их в и без того сложную реконструкцию стримящегося через UDP видеопотока окончательно придушит идею.

Лучше на своём странном запале сделай видеокодек оптимизированный под аниме, а потом, когда подымешь на это коммьюнити- БАЦ, внезапно стримь им десктоп.

А что, сложно будет вместо «векторных» окон воткнуть чёрные прямоугольники, а команды для их заполнения отдельно слать?

Да. Представь, как пользователь скроллит ленту с гифками и ты на каждую раскочегариваешь RTSP-поток с упреждением, чтобы он не ждал две секунды превращения окошка в не-чёрное. А потом он делает пальчиком «вжуууух» с целью попасть в самое начало и твой удалённый сервер от натуги выпускает маленький клубок волшебного дыма.

Чтобы это работало без эпилептических припадков у пользователя, надо уметь бесшовно переключаться с пяти маленьких прямоугольчников на один большой. А если ты уже запилишь такой гибридный многопрямоугольниковый кодек, то можно будет ещё выкинуть че ты там придумал про векторные команды и жить припеваючи.

Серьезно, миру нужен кодек для аниме и прочей мультипликации с возможностью частичного обновления кадра. Как только GPU начнут такое аппаратно жать, как сейчас жмут H.265, так и заживём.

но квотезы закрыты

Они всегда будут жить в наших сердцах бекапах.

По сути даже прямоугольники никакие не нужны, это уже я намудрил. Просто слать десктоп, на котором не отрисованы «векторные» окна. А за гифки и всё остальное внутри таких окон уже пусть HTML5 отвечает. Какие подводные?

Просто слать десктоп, на котором не отрисованы «векторные» окна. А за гифки и всё остальное внутри таких окон уже пусть HTML5 отвечает. Какие подводные?

Я че-то не понял, слать гигантский прямоугольник растрового видеопотока, поверх которого хитрой формы отдельно передающиеся векторные окна, в которых рендеринг идет через HTML 5?? Можно, только результат будет жрать трафик как просто прямоугольник растрового видеопотока и CPU клиента как браузер. Зато проблемы синхронизации их отображения тривиально чинятся выкидыванием из уравнения либо векторных окон, либо растрового видеопотока =)

Ну, при условии, что обоину мы заранее пошлём, фон будет прозрачный, а чем больше прозрачного, тем меньше весит поток. А для отрисовки приложений большная часть HTML5 должна вначале передаваться (вообще, изначально речь шла об абстрактных командах, просто HTML5 уже есть). Вопрос как раз в том, насколько это поможет сэкономить трафик. И чем дальше в тред, тем больше мне кажется, что правильный ответ — забить и пойти тыкать rustdesk + libei.

Там вон waypipe есть, может имеет смысл его попилить

Спасибо за ликбез. Вот и мне интересно стало, где там в RDP в 2021 году используется какой-то вектор и команды отрисовки.

а чем больше прозрачного, тем меньше весит поток

Рекомендую тебе поиграть с этим утверждением на практике, возможны удивления.

И чем дальше в тред, тем больше мне кажется, что правильный ответ — забить

На текущем этапе деградации человечества — очень похоже на то. Remote desktop на основе видеостриминга в гноме все ещё одной кнопкой не включить, куда уж пока замахиваться на большее. Про видео-over-VNC я с приятным удивлением прочитал аж в далёком 2021ом, а реализованным так пока и вообще ещё не увидел. А ты с амбициозными революциями в духе 80х.

libei

libei? Он пока сыроват, удивлён, что на нем уже чего-то спеет.

Рекомендую тебе поиграть с этим утверждением на практике, возможны удивления.

Ну либо по потоку на каждое окно. Но подозреваю, что польза от этого будет примерно никакая.

Про видео-over-VNC я с приятным удивлением прочитал аж в далёком 2021ом, а реализованным так пока и вообще ещё не увидел. А ты с амбициозными революциями в духе 80х.

Ну, в rustdesk VP9 используется. (Это не VNC, но нам же не обязательно VNC ограничиваться.)

libei? Он пока сыроват, удивлён, что на нем уже чего-то спеет.

Я ещё не знаю, насколько он сыроват и что там спеет, потому что подробно не приглядывался (: Просто это единственный известный мне проект по стандартизации эмуляции ввода в Wayland (и хорошо, что единственный, нечего зоопарк наводить). Надеюсь, его уже достаточно допилили, чтобы можно было добавлять его поддержку в композиторы.

Есть ещё стимовская реализация, работает тоже быстро.

Ну иксы развиваются, вот недавно поддержку xdmx выкинули, которая работала там где не требуется 3д. Поэтому то что работало 10 лет назад, может не заработать сейчас.

Просто это единственный известный мне проект по стандартизации эмуляции ввода в Wayland

Я, видать, старый дед, мне универсальный uinput милее.

Это уровнем выше и там права рута нужны. И эмуляцию событий для конкретного окна/приложения там тоже не рализуешь. В libei, правда, она тоже не реализована (:

Ну, в rustdesk VP9 используется

В xpra был режим работы через видео-кодек, это было ещё 10 лет назад, как оно сейчас не смотрел. Имхо прежде чем разрабатывать свое, имеет смысл посмотреть как сделано у других. В rdp и x11 интерфейс очень быстро работает, чего не скажешь про содержимое окна, если идёт работа например с 3д или графикой. Там прямо видно как происходит смена картинки. VNC передает только изменившуюся часть из экрана через xdamage, совместно с jpeg-turbo получается очень быстро, за исключением x11 варианта, когда опрашивается буфер экрана. В этом случае будет всегда задержка.

В rdp происходит принудительное отключение всех эффектов рабочего стола, поэтому получается использовать примитивы и все работает быстро. Нечто подобное должно быть сделано и для каждого ДЕ в линуксе.

даже заходя в удаленную сессию клиент скорее всего запустит браузер и в нем какое-то приложение. или запустит приложение на электроне. да, может когда-то и нативное запустит. хотите успеха - пилите удаленный джаваскрипт :)