Представлен (https://lists.freedesktop.org/archives/wayland-devel/2019-Ju...) проект Waypipe (https://gitlab.freedesktop.org/mstoeckl/waypipe/), в рамках которого развивается (https://mstoeckl.com/notes/gsoc/blog.html) прокси для протокола Wayland, позволяющий запускать приложения на другом хосте. Waypipe обеспечивает трансляцию на другой хост через один сетевой сокет сообщений Wayland и сериализированных изменений в буферах разделяемой памяти и DMABUF.
В качестве транспорта может применяться SSH по аналогии со встроенным в SSH перенаправлением протокола X11 ("ssh -X"). Например для запуска программы weston-terminal с другого хоста и отображения интерфейса на текущей системе достаточно выполнить команду "waypipe ssh -C user@server weston-terminal". Waypipe должен быть установлен как на стороне клиента, так и на стороне сервера - один экземпляр выступает в роли сервера Wayland, а второй клиента Wayland.
Производительность Waypipe оценивается как достаточная для удалённого запуска в локальной сети терминалов и статических приложений, таких как Kwrite и LibreOffice. Для интенсивно работающих с графикой программ, таких как компьютерные игры, Waypipe пока малоприменим из-за падения FPS в два раза и больше, вследствие задержек, возникающих при отправке данных о содержимом всего экрана по сети. Для преодоления этой проблемы предусмотрена опция для кодирования потока в форме видео
h264, но она пока применима только к линейным раскладкам DMABUF (XRGB8888). Для сжатия потока также может применяться ZStd или LZ4.
URL: https://lists.freedesktop.org/archives/wayland-devel/2019-Ju...
Новость: https://www.opennet.ru/opennews/art.shtml?num=50990
Да ну на! Быть того не может.
Правда, как и полагается вяленому, отдельным костылем, ну да ладно, лишь бы работало.Одно со статьи непонятно: на удаленном хосте граф-сеанс должен быть поднят или нет?
> на удаленном хосте граф-сеанс должен быть поднят или нет?нет
Это хорошо)Глядишь пока полностью поддержку иксов прекратят - вяленого до состояния хоть какой-то юзабельности допилят
так и было изначально задумано..
А потом заявится очередной поттеринг и заявит "Фу- мыбудем пилить новый с блеэкджеком". Вяленый это по костылям к тому моменту будет похлеще иксов сейчас.
Быстрей бы уже Wayland допилили. Огребли кучу неудобств про которые нельзя сказать "потом доделаем" или "это никому не нужно".
И вернулись к концепции иксов, запилив с нуля нормально. Учтя опыт и вайленда тоже. С обратной совместимостью по протоколу (хотя бы отдельным модулем).
не надейся.
Таких архитекторов и таких разработчиков уже не осталось.
К тому же ibm не собирается их кормить по дороге к коммунизму.В лучшем случае - удастся еще лет на десять сохранить иксы. В наиболее вероятном - через пару лет на новых интелах (не говоря уже о нвидии) они уже не будут работать.
это как с ipv6 - по задумке - г-но. По исполнению - г-но. Решает задачу, которая никому не нужна. Но никакого v8 уже не будет - никогда.
Странно, если по аналогии м x11 forwarding over ssh, то по идее сессия должна быть и на стороне клиента (по крайней мере я поднимал putty + xming в случае x11 forwarding over ssh).
В общем непонятно...
Чего? При x11 forwarding иксы нужны только на стороне сервера (т.е. там где отрисовывается приложение)
Дошло, спасибо за намек. Запутался в своих мыслях... Та машина юзалась локально и удаленно.
> Да ну на! Быть того не может.
> Правда, как и полагается вяленому, отдельным костылем, ну да ладно, лишь бы
> работало.
> Одно со статьи непонятно: на удаленном хосте граф-сеанс должен быть поднят или
> нет?Про сеанс не понятно, но костылём посчитали априори.
ПО описанию похоже на x2go. Посмотрите какие там "нет костылей".
> ПО описанию похоже на x2goТаки больше оно похоже на базовый функционал иксов, а x2go это переделаный NX - таки удаленный запуск приложений и удаленный рабочий стол вещи разные
>> ПО описанию похоже на x2go
> Таки больше оно похоже на базовый функционал иксов, а x2go это переделаный
> NX - таки удаленный запуск приложений и удаленный рабочий стол вещи
> разныеВот именно, что разные. Осталось прочесть "позволяющий запускать приложения на другом хосте" в новости и про нужность граф сеанса в ответах. Ну и сложить 2 + 2.
> Правда, как и полагается вяленому, отдельным костылем, ну да ладно, лишь бы работало.Это и есть unix-way. Прошу вернуться на свою винду и больше не заходить на этот сайт.
не нужно путать unix-way и отсутствие начального плана с последующим написанием подпорок
так изначально было задумано..
..А что если бардак и отсутствие плана и есть план?
> ..А что если бардак и отсутствие плана и есть план?Этот план предложил Лао Цзы))
Ты где был столько лет? Об плане реализовать аналог x11 forwarding вейлендовцы лет 10 назад заявляли.
Вообще-то, Wayland FAQ прямо вот сейчас написано, что network transparency это слишком большие сложности, и кому надо пусть ...бутся сами. А waypipe - это проект одного автора.
Она такая же моя как и твоя. Читать лицензию на винду не пробовал, советчик?
Куда им заходить, люди и сами разберутся без идиотский рекомендаций, спасибо.
> Правда, как и полагается вяленому, отдельным костылемА потом смотают костыли изолентой и назовут W11R6.
A пока будут сматывать радужной изолентой придумают ещё какой-то W12 и будут орать что W11r6 НеМодноНеМолодёжно и нужно срочно его дропать, а то изолента заканчивается, а костылям, которые нужно приматывать, конца края не видно.
> отдельным костылемДобро пожаловать в "делай что-то одно, но делай это хорошо".
Комбайны типа иксов не нужны.
> отдельнымЮникс-вей уже не катит, анон?
И что-же не юниксвейного в иксах?
Х всего лишь выводят картинку на монитор, независимо от того где тот монитор находится, как он подключён и к какой машине
> И что-же не юниксвейного в иксах?
> Х всего лишь выводят картинку на монитор, независимо от того где тот монитор находится, как он подключён и к какой машинеИ что-же не юниксвейного в Google Chrome?
Google Chrome всего лишь выводит доступный в вебе контент на монитор, независимо от того, какого MIME-типа этот контент (HTML, PDF, аудио/видео), как именно он заскриптован яваскриптами, обладает ли он интерактивностью с пользователем, а также "где тот монитор находится, как он подключён и к какой машине" (Chromecast)
> Для сжатия потока также может применяться ZStd или LZ4.Не, ну, для современных плоских тем, в которых поле ввода от кнопки не отличить, может, и пойдёт, но в целом я не верю в пользу этих алгоритмов применительно к интерфейсам. Уж лучше буквы с жпегным ореолом терпеть, кмк.
предположу, что отрисовка все же будет производится на клиенте и гонять битмапы по сети оно будет только тогда, когда необходимо, т.к.
> обеспечивает трансляцию на другой хост через один сетевой сокет сообщений Wayland и сериализированных изменений в буферах разделяемой памяти и DMABUF.
То есть тупо лупим все аалейты битмапов. Что ествественно, так как никаких друхиг примитивов в вейланде нет в принципе
Современным тулкитам и не нужны другие примитивы, им достаточно битмапов.
В каком DPI?
Может и SVG тоже не нужен? А то вдруг при растеризации контур попадёт меж пикселей и будет мыло, а авто-хинтинга для произвольной векторной графики пока не придумали.Скоро придётся не только память наращивать, но и количество видюх и др. аппаратных кодеков (может fpga) только чтобы банальный интерфейс не тормозил.
ИМХО, самая идеальная организация торисовки экрана - когда растеризацией занимается один процесс на весь дисплей / сеанс (привет XGL).
1. Интересно что со звуком?
2. Добавьте в новость видео https://mstoeckl.com/notes/gsoc/startup.webm и https://mstoeckl.com/notes/gsoc/typing.webm как это все работает (для проверки из блока "2019-05-14: It lives, it moves!").Пока что waypipe выглядит на уровне простого копипаста скриншотов, что делал я для иксов https://github.com/gh0stwizard/x11mirror-client
Надеюсь, что все фичи (а именно получение изменных участков экрана) выполнены лучше, чем в иксах (да-да, там тоже это есть и работает, см. асширение DAMAGE). Потому что из увиденного радости у меня 0 (шило на мыло как говорится).
А что там на счёт pipewire ?
не имеет ничего общего с обсуждаемыми в этом топике вещами.. но.. развивается. не готов.
Ну что, хейтеры "иксов"? Теперь проброс графики внезапно стал нужен, да? "Просто раньше это реально было мало кому нужно, а сейчас много у кого Raspberry Pi, на который они заходят с пробросом графики через ssh -X и VNC", да, товарищи хейтеры?
Он был нужен и он давно был в Х. А вот в Wayland только только...
В Х оно было "by design"
Так Х был и ущербен "by design"
Икс абсолютно не был ущербен пока использовался по назначению. Но вы это время не застали. Да и я, в общем, самым краем.Hint: "по назначению" - это не битмапы гонять. А что потом когда стало не хватать иксовых примитивово вместо очередных расширений влепили костыль, который кидался треугольниками - это и стало причиной всех бед.
> Hint: "по назначению" - это не битмапы гонять.Вот! Был же изначально нативный иксовый тулкит. И вместо того чтобы договориться как создавать альтернативные тулкиты, которые будут тоже нативно работать с иксами, поспешили и накостыляли.
Да не, нормально в своё время были.
Но нельзя так просто продумать в сложном продукте архитектуру, чтобы она тридцать лет работала.
Ну Хы показывают, что можно. И что инженеры из IBM/MIT/и кто-там-ещё, были действительно круты.Но да, желательно как-то это всё поддерживать.
> Ну Хы показывают, что можно.Не показывает. Критическая точка уже достигнута.
Мир меняется и сильно.
X не был ущербен, он работал и летал на таком слабом железе которое Вы себе в страшных снах представить не могли бы. Никаких ttf шрифтов только битмапы всё ьыор оптимизировано для достижения максимальной скорости... После с развитием эвм и появлением большего объёма ресурсов стали добавляться "свистелки-перделки" ... Хотя ИМХО старые иксы были и так весьма удобны.
> X не был ущербен, он работал и летал на таком слабом железе
> которое Вы себе в страшных снах представить не могли бы. Никаких
> ttf шрифтов только битмапы всё ьыор оптимизировано для достижения максимальной скорости...И небо было зеленее и травка голубее ;)
http://linux-distributions.org/docs/howto/XFree86-HOWTO.txt
> You will need a main memory of at least 8 MB and a virtual memory of at least 16 MB (i.e. main memory + swap). It is possible to run X on a 4 MB machine if you take some precautions on memory usage (look at section 4, where a package for low memory systems is described). Note that you should nevertheless have 16 MB of virtual memory. (So if you have 4 megs of physical RAM, and 12 megs of swap, you're okay.) It is recommended that you have *at least* 8 megs of physical RAM, as swap is very slow.
> With only 4 megs of physical RAM, performance will suffer greatly.(это в январе 1994, т.е. 8 МБ ОЗУ были в сегменте high-end-за-много-денег)
https://s29877.pcdn.co/wp-content/uploads/2019/02/falll-1995...
>> With only 4 megs of physical RAM, performance will suffer greatly.Вона как экономно, достаточно 4х метров. Помню, Фотошоп в те времена захотел физических 8 для запуска столь нужного фильтра.
>>> With only 4 megs of physical RAM, performance will suffer greatly.
> Вона как экономно, достаточно 4х метров. Помню, Фотошоп в те времена захотел
> физических 8 для запуска столь нужного фильтра.Да, если тактично проигнорировать "performance will suffer greatly" и то, что Иксы все же запускали не ради запуска Иксов, а как платформу для других приложений ;)
Ну и Фотошоп стоил сам по себе немало (800-1000$ ± лапоть, это на "сегодняшние", емнип, ближе к 1500$) -- т.е. скорее всего предполагалось что использоваться будет профессионалами на профессиональном оборудовании (напомню: оно тогда имело и раб. станции SGI/Irix/Solaris в качестве целевой платформы). К тому же, в требованиях к PS 3.0 для мака и NT явно были прописаны 16МБ RAM ;)
>>>> With only 4 megs of physical RAM, performance will suffer greatly.
>> Вона как экономно, достаточно 4х метров. Помню, Фотошоп в те времена захотел
>> физических 8 для запуска столь нужного фильтра.
> Да, если тактично проигнорировать "performance will suffer greatly" и то, что Иксы
> все же запускали не ради запуска Иксов, а как платформу для
> других приложений ;)Да, и то, что Фотошоп запускался в альтернативной Иксам платформе :) но точно не в NT.
> (это в январе 1994, т.е. 8 МБ ОЗУ были в сегменте high-end-за-много-денег)Сказки не говори, у меня в то время была вида 3.1 с IMB 486 DX 4-50mhz разогнанные до 100мгц, 8мб озу, винтом на целых 510мб, саундбластером прошным и даже сидирумом 2х скоростным который читал диски только после того как помоешь головку в спирте..., конечно не пень но многое тянул без проблем, а с выходом 95винды пришлось ставить 32мб потому что на 8 не запускалось, а на 16 запускалась голая винда но работало через жуткие тормоза и свапик...
>> (это в январе 1994, т.е. 8 МБ ОЗУ были в сегменте high-end-за-много-денег)
> Сказки не говори, у меняНу да - с одной стороны, вырезка из журнала за 30 октября 1995
https://s29877.pcdn.co/wp-content/uploads/2019/02/falll-1995...
> we seem to have convinced most manufacturers to atopt eight megabytes as standard
> compared with four megabytes last yearС другой -- аноним, утверждающий что все это сказки и он-то точно-точно помнит, что там было 25 лет назад, причем совсем не путая ± пару годков, угу.
Особенно "достоверно" смотрится на фоне CD-ROM привода (они тогда хоть уже и сильно упали в цене, но все еще вполне стоили пару сотен зеленых).
А так-то я тоже могу похвастать аж 8 планками по 1 МБ, винтами на 120 и 510 МБ и цельной турбокнопкой с дисплеем, который выставлялся методом тыка аж на 199 МHz -- но смысл?
Тем более, период "полураспада" ценности всех этих наворотов в те времена был существенно короче (в 1998 нормой уже были харды на 4-12ГБ, ОЗУ - в 64-96 МБ, а CPU - от 233 MHz).
> Так Х был и ущербен "by design"Не подскажете ли, в каком месте? А то пока ущербен Ваш комментарий -- именно отсутствием ну хоть какого-то обоснования.
я другой анонимус, но напишу: вы и сами знаете, в каком - в своей знаменитой сетевой прозрачности. Нельзя просто взять, отключиться и оставить Х-клиенты висеть, а потом подключиться другим Х-сервером, о нет. Только перезапуск, только хардкор. Если это не дыра в дизайне, то что тогда дыра?
> я другой анонимус, но напишу: вы и сами знаете, в каком -
> в своей знаменитой сетевой прозрачности. Нельзя просто взять, отключиться и оставить
> Х-клиенты висеть, а потом подключиться другим Х-сервером, о нет. Только перезапуск,
> только хардкор. Если это не дыра в дизайне, то что тогда
> дыра?Это отсутствие вашей внятной логики такое предположение выдвинуло... Вы друг наш явно не программист либо Вы не знаете как оно было сделано и для чего.
Просто вместо X12 парни решили изобрести свой, новый, без костылей, велосипед, "выкинув всё ненужное". Теперь "всё ненужное" втаскивается назад костылями, с использованием жевачки, изоленты и такой-то матери. То что со стороны возникают вопросы об осмысленности сего действа, по идее удивлять не должно.
> Ну что, хейтеры "иксов"? Теперь проброс графики внезапно стал нужен, да?Вот плюсую. Тоже интересно, что теперь будут говорить те, кто раньше кричал, что "сетевая прозрачность" не нужна в оправдание отсутствия этой возможности в wayland?
То, что разработчики вяленого делают выводы и работу над ошибками, пусть и мееедленноо, это в любом случае хорошо.
Чем дальше, тем больше вейланд становится похож на иксы. Точно стоило с нуля переписывать и ломать обратную совместимость?..PS: Сам "сетевую прозрачность" не использую и для меня это не критерий выбора. Но точно знаю, что этим многие пользуются, т.е. это "нужно".
Ох, чувак, как же ты не прав.Я не фанат иксов и сетевой прозрачности. Но сетевая прозрачность - это нечто уровнем выше чем гонять картинку по сети. Поэтому много и кричали по этому поводу.
Правильнее будет наверное сравнивать с расшариванием экрана чем с сетевой прозрачностью.
Сетевую прозрачность умеет: иксы. Не умеет: qt/gtk
"Точно ли стоило переписывать с нуля?" Конечно стоило!"и ломать обратную совместимость?" XWayland же, а если ты имеешь в виду что просто не доделали иксы до вейланде - Ну извини, композитор не умеет рисовать (и не должен) а поэтому иксы выкинули полностью, и оставили только возможность накладывать слои (грубо говоря)
Умеет рисовать: qt/gtk/x.org.Но для qt/gtk на иксах идёт двойная обработка картинки (упрощённо)
А теперь вспомни что все приложения в линуксе написаны на тулкитах qt/gtk. Именно популярность тулкитов заставила в линуксе поставить производительность иксов на второе место, а на первое убрать двойную буферизацию в gtk/qt
Есть и другие вяленые плюшки. Но двойная буферизация - основная причина
> Я не фанат иксов и сетевой прозрачности. Но сетевая прозрачность - это нечто уровнем выше чем гонять картинку по сети. Поэтому много и кричали по этому поводу.Почему - поэтому? Потому что сетевая прозрачность в иксах - by design, а не как в vnc?
Если нет, то почему, если да, то почему это повод кричать про то, что сетевая прозрачность не нужна?> Сетевую прозрачность умеет: иксы. Не умеет: qt/gtk
Сетевую прозрачность умеет wayland (теперь). Не умеет: qt/gtk.
Ну и в чём разница? В том, что раньше про-вейландовцы говорили, что сетевая прозрачность должна переехать в тулкиты (qt/gtk)? И что мы видим на практике?> "Точно ли стоило переписывать с нуля?" Конечно стоило!
Конечно, ведь это так увлекательно! А вот починить то, что есть - это сложно и скучно.
Веселее поставить кучу народа раком, сломав обратную совместимость.> XWayland же
Зачем мне прослойка, если я могу использовать иксы нативно?
> а если ты имеешь в виду что просто не доделали иксы до вейланде - Ну извини, композитор не умеет рисовать (и не должен) а поэтому иксы выкинули полностью, и оставили только возможность накладывать слои (грубо говоря)
Про сетевую прозрачность тоже рассказывали, что не должны, а что в итоге?
И да, то, что теперь каждый WM должен пилить часть того функционала, что ранее был объединён в X-сервере - это минус, а не плюс.> Но для qt/gtk на иксах идёт двойная обработка картинки (упрощённо)
> А теперь вспомни что все приложения в линуксе написаны на тулкитах qt/gtk. Именно популярность тулкитов заставила в линуксе поставить производительность иксов на второе место, а на первое убрать двойную буферизацию в gtk/qt
> Есть и другие вяленые плюшки. Но двойная буферизация - основная причинаОх уж эта двойная буферизация! Сколько меня ей пугают, а я всё никак не ощущаю на себе её последствия. Блин, я на атлоне с 800mhz со вторым geforce через wine на древнем дебиане запускал всякий max payne и morrowind, лет так 10-12 назад и ничего не тормозило, работало также как в win xp, которая была на том компьютере ранее. И сейчас никаких проблем с производительностью не замечаю, в игры, правда, уже лет как те же 10 не играю.
Ок, допустим проблема всё же есть.
1) Точно проблема стоит того, чтобы сломать обратную совместимость и заставить всех переписывать оконные менеджеры?
2) Точно нельзя было аккуратно выкидывать из иксов лишнее, чинить сломанное и доводить их до ума? Точно двойную буферизацию никак нельзя было починить не переписывая всё с нуля?Пока всё выглядит так, будто бы wayland будет столь же монструозен, как X, к тому моменту, как станет окончательно готов.
...зато дракона же убЪёт. :]
> ...зато дракона же убЪёт. :]Ладно бы только дракона. Я так понимаю, всякие неподдерживаемые/полуподдерживаемые оконные менеджеры, типа ion3/notion тоже не переживут отказ от исков.
Да и вообще, все WM, придётся переписывать.
выше - фигня на постном масле. кто-то помоему не оч. понимает, что такое "сетевая прозрачность". это не скриншот гонять по сети, а события. а насчет устаревания оконных менеджеров: не смеши мои тапки! опенсорс хлебом не корми, но дай написать или поюзать новый оконный менеджер! все просто счастливы будут!
> кто-то помоему не оч. понимает, что такое "сетевая прозрачность". это не скриншот гонять по сети, а события.Прекрасно понимаю, а где я говорил что-то против? Ну ок, может быть для того, что в wayland термин "сетевая прозрачность" не очень применим, на мой взгляд, это словоблудие вокруг нюансов реализации.
Речь о том, что раньше были только разговоры про то, что "сетевая прозрачность" (или как мы теперь это называем? wayland-proxy? мне пофигу. Чем протокол оперирует, то по сети и гоняют.) "не нужна". Теперь оказывается, что нужна. Речь про это, а не про то, как это сделано.И повторюсь, лично я вообще подобным не пользуюсь, для меня наличие/отсутствие сорта сетевой прозрачности - не критерий при выборе между wayland и X.
> а насчет устаревания оконных менеджеров: не смеши мои тапки! опенсорс хлебом не корми, но дай написать или поюзать новый оконный менеджер! все просто счастливы будут!
Посмотрим. Как по мне, пока всё выглядит иначе. Плюс у многих WM уже нет активных разработчиков, максимум, кто-то баги только исправляет и фиксит что-то ещё по-мелочи.
Если ты прав, то я только за, но я тут всё же пессимист. Посмотрим.
Не лень же тебе было столько накатать..> Ох уж эта двойная буферизация! Сколько меня ей пугают, а я всё никак не ощущаю на себе её последствия. Блин, я на атлоне с 800mhz со вторым geforce через wine на древнем дебиане запускал всякий max payne и morrowind,
Двойная буферизация только в qt/gtk через x.org. Не уверен, есть ли двойная буферизация у вайна, либо никогда не была - не буду утверждать.. не знаю
> Сетевую прозрачность умеет wayland (теперь)Не умеет, и никогда не будет уметь
> сетевая прозрачность должна переехать в тулкиты (qt/gtk)
К сожалению или к счастью, она никогда не переедет в тулкиты
> если да, то почему это повод кричать про то, что сетевая прозрачность не нужна?
Не берусь говорить нужна или нет, но не актуальна точно. По тому как на десктопе линукса уже минимум чисто иксовых приложений и максимум тулкитных. И выходит что сетевая прозрачность гоняет по сети не команды а картинку. Что теряет смысл вообще всей этой прозрачности, по тому как она перестает отличаться от vnc
+ Вроде как оно не идеальное.
Повторюсь. Я не фанат сетевой прозрачности. Задумка была неплохая, гонять команды а не картинку, но этого уже никогда не будет.. тулкиты скорее всего не захотят. Только от них зависит будет сетевая прозрачность в Wayland или нет. как упомянулось в этом обсуждении, возможно vglrun будет иметь смысл, но лично я в него не верю
> "Точно ли стоило переписывать с нуля?" Конечно стоило!
> Конечно, ведь это так увлекательно!Гггг. Из иксов выкинули иксы)))
Ну, это не зря сделали.. иксы теперь избыточные. Вяленый может только положить один буфер пикселей на другой буфер пикселей, обрезать уголочки, наложить тень и больше ничем не заниматься. Прекрасно же?) Не?) Хах)))Ну ладно, у иксов ещё одна проблема была - это тиринг. Уже вроде как починили. По крайней мере так говорят.. но 2 года назад я ещё видел съезжания когда скролил страничку в Firefox..
> Пока всё выглядит так, будто бы wayland будет столь же монструозен, как X, к тому моменту, как станет окончательно готов.
Да, ответ выше - вяленый не умеет рисовать, и никогда не научится. А значит монстром больше чем икс точно никогда не станет
> Двойная буферизация только в qt/gtk через x.org. Не уверен, есть ли двойная буферизация у вайна, либо никогда не была - не буду утверждать.. не знаюНикаких тормозов в qt/gtk приложениях я также не наблюдал/не наблюдаю.
>> Сетевую прозрачность умеет wayland (теперь)
> Не умеет, и никогда не будет уметьНу да, в случае с wayland это сделано немного сбоку, но суть та же.
>> сетевая прозрачность должна переехать в тулкиты (qt/gtk)
> К сожалению или к счастью, она никогда не переедет в тулкитыК счастью.
>> если да, то почему это повод кричать про то, что сетевая прозрачность не нужна?
> Не берусь говорить нужна или нет, но не актуальна точно.Мне не нужна. А кому-то нужна. То, что разработчики вяленого признали это и сделали что-то подобное - в любом случае плюс.
> По тому как на десктопе линукса уже минимум чисто иксовых приложений и максимум тулкитных. И выходит что сетевая прозрачность гоняет по сети не команды а картинку. Что теряет смысл вообще всей этой прозрачности, по тому как она перестает отличаться от vnc
Мне в принципе всё равно. Картинку так картинку. Мне был бы интересен результат, если бы я этим пользовался, а не то, что под капотом.
> тулкиты скорее всего не захотят. Только от них зависит будет сетевая прозрачность в Wayland или нет.
Но вот же waypipe, который гоняет wayland-трафик по сети, независимо от тулкита. Ну да, это не часть протокола, а сделано слегка сбоку, ну и что? Из-за различий в архитектуре тот факт, что одинаковая по смыслу функциональность реализуется различными способами - закономерен.
> Гггг. Из иксов выкинули иксы)))
Да, огорчает именно это. Сломаная совместимость.
> Ну, это не зря сделали.. иксы теперь избыточные. Вяленый может только положить один буфер пикселей на другой буфер пикселей, обрезать уголочки, наложить тень и больше ничем не заниматься. Прекрасно же?) Не?) Хах)))
Да, теперь каждый WM должен писать свой композитор. Прекрасно. Ну, в принципе, логично и последовательно: всё равно им переписывать, мы ж несовместимый протокол наколбасили.
Перенесём часть сложности на сторону клиента и будем хвастаться стройной архитектурой. А то, что сложность переехала в другую часть стека - это уже не наши проблемы! Успех!> Ну ладно, у иксов ещё одна проблема была - это тиринг. Уже вроде как починили. По крайней мере так говорят.. но 2 года назад я ещё видел съезжания когда скролил страничку в Firefox..
Никогда не могу понять, что есть тиринг. Честно, не знаю, есть он у меня или нет. Если есть, то мне видимо пофигу. И слава богу.
В любом случае, зачем чинить тиринг в иксах? Давайте запилим с нуля несовмстимый вейланд!>> Пока всё выглядит так, будто бы wayland будет столь же монструозен, как X, к тому моменту, как станет окончательно готов.
> Да, ответ выше - вяленый не умеет рисовать, и никогда не научится. А значит монстром больше чем икс точно никогда не станетМой ответ тоже выше - сам вяленый не станет. Но от этого не легче, так как сам графический стек сильно проще не стал. Просто часть сложного переехала из одного места в другое. Да и писать реализацию композитора теперь каждый WM/DE будет свою - ну это чтобы веселее с настройкой и отладкой было, при смене WM. И чтобы велосипедов, делающих одно и то же, но написанных разными командами побольше было.
всем господам, что тут кричат, что qt/gtk "к счастью" "никогда" не получать сетевую прозрачность:схема работы webgl из qt 5.12:
https://qt-blog-uploads.s3.amazonaws.com/wp-content/uploads/...
https://blog.qt.io/blog/2018/11/23/qt-quick-webgl-release-512/наработки по этому поводу у gtk:
https://www.opennet.ru/opennews/art.shtml?num=50419
> всем господам, что тут кричат, что qt/gtk "к счастью" "никогда" не получать сетевую прозрачность:Я бы не назвал это сетевой прозрачностью. Но это словоблудие в какой-то степени, да.
Основной плюс тут - браузер в качестве клиента. Оно же и минус.
Пользуюсь этим (или похожим по смыслу - как именно это сделано я не смотрел) в qbittorrent, для вебморды. Имхо этим (вебмордами), ИМХО, область применения и ограничена.
ну веб морды обычно работают через "свой" клиент-сервер протокол, типа rpc.
а у qt-webgl пересылаются вызовы/приметивы gl-я. браузер не является клиентом - там только отображается ui.>> всем господам, что тут кричат, что qt/gtk "к счастью" "никогда" не получать сетевую прозрачность:
> Я бы не назвал это сетевой прозрачностью. Но это словоблудие в какой-то
> степени, да.
> Основной плюс тут - браузер в качестве клиента. Оно же и минус.
> Пользуюсь этим (или похожим по смыслу - как именно это сделано я
> не смотрел) в qbittorrent, для вебморды. Имхо этим (вебмордами), ИМХО, область
> применения и ограничена.
> ну веб морды обычно работают через "свой" клиент-сервер протокол, типа rpc.
> а у qt-webgl пересылаются вызовы/приметивы gl-я. браузер не является клиентом - там только отображается ui.Я больше про то, что было в новости про gtk, если я всё верно понял. Qt, ЕМНИП, тоже умело выводить гуй не нативно, а как html+js морду. Кажется, в qbittorrent оно так и работает, в вебморде.
Могу впрочем ошибаться.
qt-webgl там, скорее всего, абсолютно не при делах, согласен.
> ну веб морды обычно работают через "свой" клиент-сервер протокол, типа rpc.
> а у qt-webgl пересылаются вызовы/приметивы gl-я. браузер не является клиентом - там
> только отображается ui.Таки стало интересно и я немного заморочится вопросом реализации web ui в qbittorrent.
Кажется, я всё соврал в 131 и web ui в qbittorent написан руками, без использования спец. возможностей qt.
Т.е. тут я не в тему сказал совершенно, да.
>а на первое убрать двойную буферизацию в gtk/qtЗа новостями про Xfree не следите ? Посмотрите архив , уже года как 3 устранили эту проблему.Да опять небольшой костыль-расшерение но во всяком случае смотрел опции сборки в kubunty,расширение включено и не кто не жалуется.С тирингом не знаю как обстоят дела, по крайне мере с переходом на новую версию
дистрибутива не разу его не ловил.
> Да опять небольшой костыль-расшерениеБыли (MIT-)SHM, XDBE. А что добавили?
>Были (MIT-)SHM, XDBE. А что добавили?Я про них и имел в виду, просто у LTS дистрибутивов поддержка вместе с графическими библиотеками добавлена совсем недавно, по умолчанию даже если и Х сервер поддерживал это расширение ,не факт что клиентские либы работали с этими расшерениями.
Видь как не грустно но с безопасностью у Х плохо.Любое костыльное приложение может обрушить графический сеанс,вот и разработчики дистрибутивов осторожничали.
В качестве примера костыльного приложения могу назвать редактор антиворд (врядли уже потдерживаеться в пакетах), недавно проверял по прежнему вышибает графический сеанс.
это не сетевая прозрачность. это не то чтоб разработчики вэйланда. и это даже не часть вэйланда. и да вэйланд не замена иксам поэтому сохранять совместимость было не с чем. но её таки добавили те кому было надо.
> это не сетевая прозрачность.Я понимаю разницу между прокси, приделанным сбоку и передачей команд отрисовки через сокет (сетевой или unix).
Какое правильное название для того, чем является waypipe?> это не то чтоб разработчики вэйланда. и это даже не часть вэйланда.
ОК.
> и да вэйланд не замена иксам поэтому сохранять совместимость было не с чем.
Вейланд замена иксам. Совместимость - это я не в контексте сетевой прозрачности/проксирования wayland, а про то, что как минимум тулкиты и WM нужно портировать на wayland.
> но её таки добавили те кому было надо.
Мне не надо. Но в любом случае, хорошо, что добавили.
> Чем дальше, тем больше вейланд становится похож на иксы.Чем, интересно, становится похож? Поддержкой тысяч программ? Кроссплатформенностью? Сетевой прозрачностью? Продуманными оконными менеджерами, которые соединяют довольно эклектичные программы в единое пространство?
>> Чем дальше, тем больше вейланд становится похож на иксы.
> Чем, интересно, становится похож?Тонной расширений. Сам по себе wayland довольно бесполезный. См. wayland-protocols.
> Поддержкой тысяч программ?
Тысяч? Когда я пробовал, у меня штуки 3-4 набралось, всё остальное через xwayland.
> Кроссплатформенностью?
Только в перспективе. Текущие реализации достаточно линукс-специфичны, судя по всему.
> Сетевой прозрачностью?
Приделанной сбоку от самого протокола. Но да, раньше кричали, что это "не нужно".
> Продуманными оконными менеджерами, которые соединяют довольно эклектичные программы в единое пространство?
Несколько недоделанных портов некоторых иксовых WM?
Пока, увы, несравнимо.
Ну, то есть, жалкое подобие левой руки. Это не называется похож.Если вы считаете, что расширения - это плохо, то зря. Это отличный механизм сделать программу долгоживущей. Он, кстати, реализован много в каких известных и замечательных программах.
> Ну, то есть, жалкое подобие левой руки. Это не называется похож.Ну это пока. Сейчас подвезут оконных менеджеров, со своей реализайцией подмножества функционала иксов внутри и всё будет. Да и расширений пока немного.
> Если вы считаете, что расширения - это плохо, то зря.
Я к этому никак не отношусь. Но слышал от любителей вейланда, а может даже и от разработчиков, что изобилие раширений иксов на каждый чих - это уже проблема и костыли.
Я не столько против вейланда (мне на самом деле без разницы, если всё, что мне нужно будет работать), сколько бомблю от того, что его разработчики сначала критикуют иксы за что-то, а потом пилят у себя примерно такое же по смыслу, не забыв предварительно сломать совместимость.
> Сейчас подвезут оконных менеджеров, со своей реализайцией подмножества функционала иксов внутри и всё будет. Да и расширений пока немного.Не будет - оно развалится под собственной тяжестью. Выглядит это так: расширения формально есть, но фактически они друг с другом конфликтуют, нестабильно работают, ряд заявленных возможностей недореализуют. В результате, на бумаге Wayland есть, а по факту пользоваться им невозможно.
>> Сейчас подвезут оконных менеджеров, со своей реализайцией подмножества функционала иксов внутри и всё будет. Да и расширений пока немного.
> Не будет - оно развалится под собственной тяжестью. Выглядит это так: расширения формально есть, но фактически они друг с другом конфликтуют, нестабильно работают, ряд заявленных возможностей недореализуют. В результате, на бумаге Wayland есть, а по факту пользоваться им невозможно.Ну или так. Я вяленого пробовал полтора раза из любопытства, не более. Мне в принципе не важно, как именно сфейлится вейланд - помрёт не выдержав собственного веса или станет такой же монструозный и сложный как иксы и ничем не будет их превосходить.
Я не вижу смысла начинать пользоваться вяленым до тех пор, пока 1) он не достигнет паритета по функционалу с иксами 2) более 70-80 процентов ПО не начнёт корректно с ним работать (нативно, не через xwayland). И, в принцие, если такое время не наступит, я ничуть не огорчусь, мне и с иксами хорошо.
Кажется, в #70 был сарказм, да? Ввиду видимо того, что тогда я ещё не ложился спать с субботы, я не распознал его и ответил слегка странно. Wayland, на мой взгляд, становится похож на иксы в плане их худших черт, а не в плане того, что он становится столь же готов к повседневному использованию.
Как был не нужен, так и остался. Уже 10+ лет я не использовал его, и не вижу причин использовать. Под удалённые вещи есть ssh и tmux. Если мне приходится запускать emacs удалённо, я вполне могу потерпеть текстовый интерфейс. А ff я не запускаю удалённо.
Вашличество, ну как скажете :)// а вот я порой запускаю, и не только fx...
Мало ли кто и что запускает. Откуда вообще у людей взялась эта идея, что если для вейланда появилась возможность удалённого запуска, то она станет нужна тем, кому она была не нужна?
Действительно, ведь очевидно, что все люди одинаковые, думают как ты и ходят строем как ты.
нет. все люди думают как я. с вами нелюдями у нас нет ни одной хоть отдалённо схожей мысли!
Я не знаю, как ты пришёл к этой мысли, но даже если мы её примем, то значит ли это, что появление сетевой прозрачности в wayland должно изменить моё отношение к сетевой прозрачности?
Внешне — да, внутренне — нет. Сначала ты всегда был против сетевой прозрачности, потом всегда был за сетевую прозрачность. Двоемыслие такое двоемыслие.
> Внешне — да, внутренне — нет. Сначала ты всегда был против сетевой
> прозрачности, потом всегда был за сетевую прозрачность. Двоемыслие такое двоемыслие.Это обязательно? Если я не пойду на это, то меня как-то кто-то покарает больно?
Вариант, что она появилась именно потому, что была нужна, не рассматривается?
> Вариант, что она появилась именно потому, что была нужна, не рассматривается?Нет конечно. Программисты часто пишут код по той же причине, по который коты лижут себе яйца. То что написано на github'е, пока наводит на мысль о том, что именно по этой причине waypipe и был написан.
Коты инстинктивно чистоплотны, что бы не отпугивать добычу запахом. Причина — необходимость выживания.
> Коты инстинктивно чистоплотны, что бы не отпугивать добычу запахом. Причина — необходимость
> выживания.Если эрудиция тебе мешает понимать собеседников, то твоя эрудиция ничем не отличается от наскальной росписи с точки зрения полезности.
Что бы демагогия сработала, необходимо говорить правду, иначе она окажется из некоего пальца... что там подсказывает эрудиция?
> Что бы демагогия сработала, необходимо говорить правду, иначе она окажется из некоего
> пальца... что там подсказывает эрудиция?Откуда я знаю? Эрудиция -- это твоё свойство, не моё.
Кто здесь?
> Кто здесь?Коты?
> Коты?Ааа... тебе всё интересно, почему ты приплёл кота? Потому что у тебя аргументов против "было нужно" не было, нет и не предвидится.
>> Коты?
> Ааа... тебе всё интересно, почему ты приплёл кота? Потому что у тебя
> аргументов против "было нужно" не было, нет и не предвидится.Я не видел возражений к которым можно было бы предъявлять аргументы или контраргументы. Ты говорил что-то про котов, я решил поддержать.
>>> Коты?
>> Ааа... тебе всё интересно, почему ты приплёл кота? Потому что у тебя
>> аргументов против "было нужно" не было, нет и не предвидится.
> Я не видел возражений к которым можно было бы предъявлять аргументы или
> контраргументы. Ты говорил что-то про котов, я решил поддержать.Ну ты даёшь.)) Разумеется, ты не мог их увидеть, поскольку они невозможны в принципе. Автору было надо, он написал, на что тебе и намекнули. Кто ты вообще такой, что бы возражать против его созидания? при том — возражать постороннему. Не Наполеон ли ты случаем?)))
Я по работе запускаю ежедневно много чего удалённого. И оно работает, от tkdiff до Wolfram Mathematica.Ну у нас с вами разные работы. И что? Большая часть населения шарика вообще только со смартфонами знакома, а клавиатуру вообще никогда не трогала. Будем заключать, что "компьютеры нинужны"?
"For the last few weeks, I've been working on a program"
"Waypipe has become stable and usable enough at this point"нормально так чувак натворил.
сколько лет то такую фичу ждали (наверное ждали)
А многие ли в самом деле ждали, а не ради того чтобы похейтить вэйланд?
Чуваку понадобилось - чувак сделал. А специалисты сидят и кудахчут.
Специалисты не чахнут, они работают себе и получают за это деньги. Как бы это не казалось тебе противоестественным. Ты поскольку не сталкивался, даже не представляешь себе уровень сложности по интеграции всего этого ада малосвязного ада в готовое решение.
> Специалисты не чахнут, ониЕсли специалисты для тебя "они", а не "мы", дальше можно не читать.
Специалисты прекрасно знают, что не надо работать над изначально мертворожденными решениями, типа Wayland. А решения под Xы вполне себе ваяют, если надо. Вот я давеча запакетировал отличный терминал под X, под названием xst.
Это даже не костыль, это кучка реечек, перевязанных проволокой, используемых в качестве подпорки.
Тут все знают что такое X11.
УРА
Автор новости не в курсе чем ssh -X отличается от xpra. Вопрос в том, где происходит рендеринг. Так вот, судя по описанию waypipe - это совсем не ssh -X.
Читайте внимательнее, в новости ssh -X приводится как аналог использования SSH в качестве транспорта для проброса X11. Точно также пробрасывается сокет Waypipe. Рендеринг ни в том ни в другом случае с SSH никак не связан.
Печему нельзя просто гнать Opengl команды по сети?
Это в сторону vglrun? - https://wiki.archlinux.org/index.php/VirtualGL
> Печему нельзя просто гнать Opengl команды по сети?Когда-то в этом не было проблем. Но когда количество треугольников на сцену перевалило за миллион (и не стоит забывать про текстуры и многое другое), то стало дешевле передавать готовые пиксели, которых тоже миллион, но удобной для сжатия картинкой, чем 3d примитивы. Вот здесь концепция сетевой прозрачности opengl и умерла. Нет той прозрачности больше. И с каждым годом видеокарта превращается во всё более автономный и мощный компьютер.
А на кой там эта гора треугольников? Хотя правильным ответом было бы, конечно, плеваться тулкитными сообщениями и полностью абстрагировать рисовалку
> Хотя правильным ответом было бы, конечно, плеваться тулкитными сообщениями и полностью абстрагировать рисовалкуНу то есть в тех же Иксах заменить старые команды рисования 2Д примитивов, завязанных на физические пиксели, на новые более высокоуровневые 3Д? А еще лучше добавить новые команды, а не заменить.
Для этого требуется провести очень серьёзную аналитическую работу: нужно проанализировать примитивы и темы тулкитов, шрифтов и т.д. После этого необходимо вычленить примитивы и провести ортогонализацию API; потом определить, как именно нужно реорганизовывать старую рисовалку X, желательно без потери совместимости. И можно ли вообще это сделать.Возможно, там будет место для спец. шейдеров и даже анализа этих шейдеров в плане тотальности/использования ресурсов.
В общем, это действительно серьёзная и крутая инженерия, но кодить что-либо можно будет начинать примерно через год. И, конечно, это не весело и довольно тяжело (я подобным занимался, но значительно более мелким, естественно).
Ну то есть проделать ту же работу, что когда-то для своего времени была проделана при создании X11.
Но, судя по всему, теперь уже кишка тонка такое сделать. Ремесленников расплодилось до черта, а настоящие мастера, похоже, постепенно уходят.
Да и, я так понимаю, не хотят сейчас люди тратить время на что-то фундаментальное. Надо побыстрее что-то слепить на коленке, чтобы быстрее получить хоть какой-то профит.
> Ну то есть проделать ту же работу, что когда-то для своего времени
> была проделана при создании X11.Ну да.
> Но, судя по всему, теперь уже кишка тонка такое сделать.
Почему, можно. Всё есть, просто нет заказа на это.
Близко, но неверно. Если на клиенте слабая видео карта, которая не умеет в распоследний OpenGL, то такой OpenGL по сети никому не нужен. Поэтому действительно нужно гонять пиксели.Более того, изначально иксы такими и планировались. Оптимизация в виде выдачи кусочков изменного экрана появились позднее, но смысл остался тот же - всегда сервер рисует со своей видеокарты. Более актуальный пример на сегодняшний день - стриминг игр (стриминг отличается от удаленного стола только в том кто является клиентом: ютуб или конкретный комп; авторизация на сервере дело 10е).
> когда количество треугольников на сцену перевалило за миллионИМХО, оно умерло когда появились шейдеры. Появилась возможность вернуть назад охренительных размеров результат, который потом опять придется передавать.
>Но когда количество треугольников на сцену перевалило за миллионА потом кто-то дотошный выяснил, что upscale битмапа с букавками для другого dpi тоже не торт. :)
Он бы умел как РДП - запустил приложение удалённо на ресурсах там видеокарты, отключаешся, приложение продолжает работать, подключаешся и продолжаешь с тем же экраном/окном.Секьюный и простой вариант такого не существует. Что бы сохранять между подключениями, работало на удалённой видеокарте.
Есть сложные и очень жрущие сеть и процессор секъюрные варианты. Они - трудно и сложно.
в sway, говорят, добавили rdp backend... еще не пробовал.
Вот не *** было убивать иксы, для них надо слать команды отрисовки, а не видеопоток.
Мир движется в сторону упрощения технологий и человека. А иксы по сложности уже сопоставимы с ядром.
Да это заметно. Упрощённые люди всё чаще встречаются. Главное не переборщить, а то котики и пёсики окажутся сложнее и умнее.
>для них надо слать команды отрисовки, а не видеопотокЭто давно не так, все тулкиты рисуют кнопки и прочее самостоятельно, и уже давно и не используют Х для этого. Тут вопят про великолепную сетевую прозрачность Х, а по сути последние годы это костыльный протокол в котором гоняют готовые битмапы которые рисуют тулкиты
А нельзя ли сделать, чтобы тулкиты не гоняли картинки для виджетов? Как мы вообще дошли до жизни такой?
Можно. Если лично вы готовы довольствоваться тулкитами уровня Xaw.
А почему для кутей так нельзя?
Попробуйте представить сколько раз надо дергать иксовые примитивы для отрисовки окна с более-менее современно выглядящим гуем и как это все будет моргать и дергаться при перерисовке.Кстати куте первых версий именно так и делало, потом разработчики задолбались.
Во времена KDE 2 и 3 точно было можно
> рисуют кнопки... самостоятельно
> ...и уже давно и не используют Х для этогоВ Qt есть бекэнды raster и native. Картинки гоняет raster и это сильно тормозит по сети (даже через 100-мегабитное подключение без роутера). native по сети тормозит на порядки меньше.
Локально вроде бы raster шустрее native, но тесты многие не гоянли, а на глаз разница не заметна.
И на кой это нужно? Серьезно, помимо задачи нарисовать Х есть соседняя задача сделать с этим Х что-то У причем на CPU. Пример - игры.Будь все так просто, то где сетевухи с пропускной способностьюю шин уровня PCI-Ex16? Поэтому нет смысла держать логику на клиенте, а сервер использовать только ради видяхи.
Это кажется что скорость PCI-E избыточна, но это не так, т.к. кроме GPU всегда участвует CPU. Ок, давайте гнать команды по сети прямо в CPU сервера и что получим? Херню получим.
Даже если сделать так, что хватит команд графического сервера для отрисовки всех базовых вещей, то каковы будут возможности? Как вы собрались раскодировать видео? Да-да, это по вашей логике сервер должен передать клиенту стрим файла, а клиент должен решить как его рисовать на сервере. Или логика у вас вот для видео мы сделаем исключение? Что за х? Кроме нарисовки видео есть задачи конвертирования из формата А в формат Б и снова это будет исключение, так? Ок, хочу использовать удаленно Blender и снова исключение?
А знаете почему выходит так много исключений? Потому что идея г. И главная проблема в том, что никто ради этой идем не станет переписывать тот же Blender. И еще тонна софта, который вы просто не осилите за все свою жизнь.
Хотите сделать иначе - вперед и удачи.
> И на кой это нужно? Серьезно, помимо задачи нарисовать Х есть соседняя
> задача сделать с этим Х что-то У причем на CPU. Пример
> - игры.Это ведь не работа иксов. Работа иксов - GUI.
> Даже если сделать так, что хватит команд графического сервера для отрисовки всех базовых вещей, то каковы будут возможности? Как вы собрались раскодировать видео?Для (рас)кодировки видео, аудио, графики нужен отдельный сервер.
> Да-да, это по вашей логике сервер должен передать клиенту стрим файла, а клиент должен решить как его рисовать на сервере. Или логика у вас вот для видео мы сделаем исключение?0. есть базовы протокол. Этот базовый протокол - основа всех серверов. В него входит протокол обмена командами и базовые команды:
а) создания и удаление серверных объектов. При разрыве соединения все объекты удаляются.
б) определения их типа
в) проксирования соединения к другому серверу. При проксировании владельцем объекта становится проксирующий сервер. Проксирование идёт сессиями, при разрыве соединения сессия закрывается аварийно, при любом закрытии сессии закрывается соединение с проксируемым сервером и объекты удаляются.1. клиент подключается к иксам
2. клиент спрашивает иксы про сервер кодирования, заданный в конфиге
3. клиент инициирует проксирование через иксы на сервер кодирования
4. иксы становятся владельцами объектов декодирования
5. соответственно декодированному видео не надо покидать машинуРазумеется, можно использовать внешний сервер декодирования. И совсем необязательно, чтобы сервер декодирования реализовывал декодирование на GPU, могут быть и асики.
> Кроме нарисовки видео есть задачи конвертирования из формата А в формат
> Б и снова это будет исключение, так?Отлично вписывается в предыдущую корцепцию.
Уже после пункта про конфиги выходит, что клиенту нужно 100500 конфигов под каждое приложение. Очумительно.
Я не говорю, что это не взлетит, но... флаг в руки еще раз.
И не говорите, что конфигов нужно 1-2. Вы просто пишете код, а потом расскажите и покажите результат.
Битмапы, битмапы...Отл. В чём проблема сделать при старте программы обмен битмапами-кусочками интерфейса между клиентом и сервером с их id? Далее работает обычный X-протокол, только гоняются id кастомных примитивов, о которых мы сообщили на старте. Набор таких примитивов будет ограничен(кнопка, поле вода, прокрутка и т.п.). Более того, можно с клиента на сервер передавать что-то вроде шейдеров - правила по которым будут изменяться данные кастомные примитивы. Например масшабирование кнопок, прокруток и т.п.
Хотя можно просто свести всё к передаче на старте id и текста шейдера. Будет достаточно.
Ага и сразу
1. отвалятся карты без шейдеров
2. получим ворох уязвимостей.
> 1. отвалятся карты без шейдеровЯ сказал похоже на шейдеры. Оно не обязано компилироваться в реальные шейдеры, если нет поддержки на машине.
> 2. получим ворох уязвимостей.
Это с какой такой стороны они придут?
Ты сейчас описал web-приложение.
Ты сейчас раскрыл планы Гуглей по захвату мира.
Ты сейчас описал алгоритм сжатия.
Нет. Это не он.
Я все не пойму зачем это нужно и кому. Ясное дело что мои пилят этот костыль то значит кого-то интересует.
Я так думаю на серверах графических приложений, принципе как и графического стака не должно быть. Если уж очень нужен удалённый рабочий стол то vnc, rdp открытых и закрытых по типу как teamviewer полно под любую задачу и цели
>Я все не пойму зачем это нужно и кому.
>Если уж очень нужен удалённый рабочий стол то vnc, rdp открытых и закрытых по типу как teamviewer полно под любую задачу и целиКто из них умеет пробросить окно/окна одного приложения, причём вид этого приложения и взаимодействие с оным будут нативными для машины-клиента?
Опа...
Только поговорили ... ловите:
https://www.opennet.ru/openforum/vsluhforumID3/117691.html#39
И постепенно Wayland превращается... превращается Wayland... в Иксы!
> опция для кодирования потока в форме видео h264За потоковое вещание ведь отдельные деньги нужно платить...
А опции для vp9 не ли? во многих ведь железках доступно, спасибо гуглу.
av1 давно уже пора смотреть...
> А опции для vp9 не ли? во многих ведь железках доступноЯ правильно понимаю, что на линуксах - это только на новых Intel доступно?
https://en.wikipedia.org/wiki/VP9#Hardware_device_supportВ качестве сервера в такой схеме может выступать камушек у которого в колонке "Encoding" зелёная галочка (ну либо программно делать сжатие, если это очень быстрый камушек). А в качестве клиента - любой камушек из этой таблице.
И наверняка таблица это не совсем актуальна уже (в том смысле, что уже не модно её расширять).
...короче и вяленый лажа ...позоду болееменее найс +возм из коробки кроссплатформенности только xrdp и имеет реальность альтернативы (вот бы только из коробки в нем еще переключ раскладки была без танцев с бубном!)
