Могу заявить как эксперт, что на этой страничке в лисе некорректно отображается svg

Зачем это нужно?

У меня нормально всё в Лисе

Чтобы приложухи и игрули запускать удалённо

Эксперная оценка? Получится упрощенный вариант иксов, который не могли получить из самих иксов потому что «аряяяя нам нужна обратная совместимость с говном из 80-х».

Оно конечно не помешает. Пущай будет. Но я не вижу в этом большого смысла и насущной необходимости. Вся суть вейланда в том, что приложения имеют как можно более непосредственный доступ к видеопамяти, с минимальной буферизацией и оверхедом на пути картинки от приложения к экрану. При работе через сетевую прозрачность все эти преимущества теряются.

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

EXL

Ну тут вопрос приоритетов. У иксов сетевая прозрачность в основе архитектуры, в ущерб фичам типа прямого доступа, что странно. А у вейланда наоборот.

Игрули? Тормозить не будет?

Чем rdp/vnc/temviewer хуже?

Какой нафиг Damage Notifications в Wayland?

Зависит от мощности железа, ширины канала и сложности картинки

А, всё, дошло.

Можно, конечно. Можно взять Qt с его сигналами-слотами за основу (потому что это уже почти готовый RPC) и подвести под него сеть. Весь вопрос в том, чтобы это сделать. Это долго, трудоёмко и нафиг никому не упало.

tl;dr

Приложения смогут пережить разрыв связи и восстановиться при новом подключении или будет как в иксах?

У меня нормально всё в Лисе

+1

и из-за этого всё было очень быстро, в т.ч. и через сеть.

В 1999 г я вполне успешно работал в Netscape на SUNовской машине, расположенной в Хьюстоне. Окно которого прорисовывалось средствами X-Window у меня на домашнем ПК в Питере. При этом к Сети я был подключен через самопальный dial-up на 28800 бот. Единственным условием комфортной работы было задействование модуля сжатия в X-Window, к сожалению, подробностей уже не помню, но тогда это было каким-то очередным расширением протокола X11. Помню, что его включение очень сильно улучшило отзывчивость Netscape. Единственной проблемой был исходный запуск приложения - окно несколько минут прорисовывалось, но потом довольно шустро работало.

Потому что оно битмапы/пиксмапы иконок интерфейса передавало. А потом просто кидало команды рендеринга - шрифты в иксах в то время были с клиентской стороны.

Потому что оно битмапы/пиксмапы иконок интерфейса передавало. А потом просто кидало команды рендеринга - шрифты в иксах в то время были с клиентской стороны.

Ну да. Собственно говоря, выше alexferman именно об этом и писал.

Зачем оно там?

А ssh сейчас так делает?

Steam Link уже есть

А это на уровне ОС будет

А сейчас можно сделать такое же, только современное и невырвиглазное?

Нет.

Почему:?

Потому что требования взаимно противоречивые. С одной стороны нужно ограничиться набором требований и заморозить их так, чтобы можно было оформить всё в протокол, обязательный к исполнению всем. С другой стороны, ты затребовал «современное и невырвиглазное». А это нельзя сделать в замороженном виде. Просто потому что современное в 2019 не будет современным в 2021 по определению слова «современный». Вырвиглазность это вообще субъективное понятие.

Сейчас это можно сделать лишь через сами тулкиты, на стороне Qt и GTK реализовывать надо, а для остального Legacy – битмапами.

Но так как сложность интерфейсов далеко ушла от примитивов вида «отрисуй кнопку размером 64,10 по координатам 10,10 и надписью «Сделать хорошо»», то сейчас никто с этим ковырятся не будет и кидать будут битмапы, как и раньше. Нужно в сторону крутых алгоритмов сжатия битмапов смотреть. Вон как в AVI был какой-то кодек, две минуты записи почти статичного экрана жал в 100-200 КБ.

чтобы вяляный наконец догнал Х по фичам

Разве такая цель ставилась?

судя по этой новости уже да

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

lbxproxy это называлось. Сейчас протокол NX есть (реализовано в x2go) с той же целью, но результаты ну куда круче. Я как-то пробовал GIMP на 64 kbps запустить и он даже юзабельным был (Ну, если не считать сжатия изображения).

Приложения смогут пережить разрыв связи и восстановиться при новом подключении или будет как в иксах?

Чистый протокол X11 имеет сегодня смысл только в локальных сетях с надежным соединением и скоростью от 100 Mbps и выше. Лучше гигабитка. Для работы на медленных сетях с большими задержками, разрывами есть протокол NX, который есть пожатый X11 с кучей оптимизаций и кешированием. x2go переживает падение сессии.

А потом просто кидало команды рендеринга - шрифты в иксах в то время были с клиентской стороны.

Только на стороне X-сервера. а не X-клиента. server-side fonts. Это сейчас они на стороне X-клиента и в сегодняшних условиях, да и при работе на сетях с большой latency, это лучше, так как client-side fonts не подвержены roundtrips. А в те времена когда шрифты были на сервере, были проблемы, когда X-клиенту нужно было для отрисовки элементов интерфейса запрашивать метрику шрифта у сервера, а это дает чистый roundtrip. В принципе, тогда шрифты были на server-side, потому что гетерогенные решения были, разные поставщики терминалов, X-серверов со своими шрифтами, которые никому не дают, очень разные устройства отображения. Сейчас уже смысла нет, но иногда удобно все же.

Я как-то пробовал GIMP на 64 kbps запустить и он даже юзабельным был (Ну, если не считать сжатия изображения).

Nomachine утверждали, что и на 9600 будет работать. И кто-то даже пробовал, в сети писал. Ну и сравнивали скорости между VNC, NX и RDP.

lbxproxy это называлось.

Точно, спасибо за напоминание.

Сейчас протокол NX есть (реализовано в x2go) с той же целью, но результаты ну куда круче.

Много слышал, но пользоваться не доводилось пока.

Только на стороне X-сервера. а не X-клиента. server-side fonts.

Это классика - сколько себя помню, всегда путают понятия сервера и клиента, когда речь о X-window заходит ;).

Костыли в иксах это хорошо, но все-таки, что там в сабже? Улучшения ожидаются?

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

Вообще, практически все тулкиты рисовали примитивами раньше. Шрифты - примитивы, прямоугольники (закраска областей), линии, пиксмапы на сервере были, ими оперировали. Потом, когда Render Extension появилось, то еще 2D-примитивы появились: трапезоид, треугольник, градиенты, глифы. Если установить renderer у тулкита в render, то вот такими примитивами будет рисовать.

А насчет древнего фреймфорка... Был и есть Xt (https://en.wikipedia.org/wiki/X_Toolkit_Intrinsics). На его основе реализованы Xaw, Motif и еще там кто-то был. Но рисование это все равно сводилось к графическим примитивам X-протокола. Этот фреймворк был просто для того, чтобы часть вопросов взаимодействия с иксами спрятать от тулкитов.

Можно тему к motif сделать.

Если установить renderer у тулкита в render, то вот такими примитивами будет рисовать.

То есть в x11 (он так чаще называется). И можно посмотреть при помощи xtrace, что приложение гонит на X-сервер. Например, evince на GTK3, если грепнуть вывод по RENDER-Request выдает, что отрисовка идет графическими примитивами trapezoids, glyph (буковки - отдельный примитив), закраска областей и т. д. (в Render примитивов мало):

RENDER-Request(139,8): Composite op=Over(0x03) src=0x01800044
mask=0x018009c6 dst=0x018009b7 xSrc=93 ySrc=30 xMask=0 yMask=0 xDst=93
yDst=30 width=17 height=17

RENDER-Request(139,7): FreePicture picture=0x018009c6

RENDER-Request(139,5): ChangePicture picture=0x018009b7
values={clip-mask=None(0x00000000)}

RENDER-Request(139,7): FreePicture picture=0x018009c4


RENDER-Request(139,26): FillRectangles op=Minimum/Clear(0x00)
dst=0x018009ce color={red=0x0000 green=0x0000 blue=0x0000
alpha=0x0000}; rects={x=0 y=0 w=76 h=12};

RENDER-Request(139,10): Trapezoids op=Over(0x03) src=0x0180043e
xSrc=101 ySrc=37 dst=0x018009b7 maskFormat=0x00000024
trapezoids={top=37.828125 bottom=38.324219 left={x1=101.828125
y1=37.828125 x2=101.214844 y2=38.324219}; right={x1=101.828125
y1=37.828125 x2=102.535156 y2=38.535156};},{top=37.828125
bottom=38.324219 left={x1=8.171875 y1=37.828125 x2=7.464844
y2=38.535156}; right={x1=8.171875 y1=37.828125 x2=8.777344
y2=38.324219};},{top=38.324219 bottom=38.535156 left={x1=8.171875
y1=37.828125 x2=7.464844 y2=38.535156}; right={x1=8.777344
y1=38.324219 x2=9.468750 y2=38.695312};},{top=38.324219
bottom=38.535156 left={x1=101.214844 y1=38.324219 x2=100.531250
y2=38.695312}; right={x1=101.828125 y1=37.828125 x2=102.535156
y2=38.535156};},{top=38.535156 bottom=38.695312 left={x1=101.214844
y1=38.324219 x2=100.531250 y2=38.695312}; right={x1=102.535156
y1=38.535156 x2=101.769531 y2=39.156250};},{top=38.535156
bottom=38.695312 left={x1=7.464844 y1=38.535156 x2=8.222656
y2=39.156250}; right={x1=8.777344 y1=38.324219 x2=9.468750
y2=38.695312};},{top=38.695312 bottom=38.917969 left={x1=100.531250
y1=38.695312 x2=99.781250 y2=38.917969}; right={x1=102.535156
y1=38.535156 x2=101.769531 y2=39.156250};},{top=38.695312
bottom=38.917969 left={x1=7.464844 y1=38.535156 x2=8.222656
y2=39.156250}; right={x1=9.468750 y1=38.695312 x2=10.210938
y2=38.917969};},{top=38.917969 bottom=39.000000 left={x1=99.781250
y1=38.917969 x2=99.000000 y2=39.000000}; right={x1=102.535156
y1=38.535156 x2=101.769531 y2=39.156250};},{top=38.917969
bottom=39.000000 left={x1=7.464844 y1=38.535156 x2=8.222656
y2=39.156250}; right={x1=10.210938 y1=38.917969 x2=11.000000
y2=39.000000};},{top=39.000000 bottom=39.156250 left={x1=7.464844
y1=38.535156 x2=8.222656 y2=39.156250}; right={x1=102.535156
y1=38.535156 x2=101.769531 y2=39.156250};},{top=39.156250
bottom=39.617188 left={x1=8.222656 y1=39.156250 x2=9.082031
y2=39.617188}; right={x1=101.769531 y1=39.156250 x2=100.910156
y2=39.617188};},{top=39.617188 bottom=39.898438 left={x1=9.082031
y1=39.617188 x2=10.015625 y2=39.898438}; right={x1=100.910156
y1=39.617188 x2=99.976562 y2=39.898438};},{top=39.898438
bottom=40.000000 left={x1=10.015625 y1=39.898438 x2=11.000000
y2=40.000000}; right={x1=99.976562 y1=39.898438 x2=99.000000
y2=40.000000};};

RENDER-Request(139,24): CompositeGlyphs16 op=Over(0x03) src=0x018005dc
dst=0x018009b7 maskFormat=None(0x00000000) glyphset=0x01800067 xSrc=16
ySrc=28 glyphcmds={deltax=16 deltay=28
glyphs=0x03b3,0x03d7,0x03cf,0x03d5,0x03e0,0x03d7,0x03e1,0x0b09; };

RENDER-Request(139,24): CompositeGlyphs16 op=Over(0x03) src=0x01800734
dst=0x018009b7 maskFormat=None(0x00000000) glyphset=0x01800067 xSrc=16
ySrc=27 glyphcmds={deltax=16 deltay=27
glyphs=0x03b3,0x03d7,0x03cf,0x03d5,0x03e0,0x03d7,0x03e1,0x0b09; };

Postscript как API для GUI

Чтобы два раза не вставать: а не может ли достопочтенная публика разъяснить, почему не взлетел PS как стандарт для GUI?

И скорее всего это будет говном

Расширение DPS (Display PostScript) было когда-то для иксов даже. И его поставляли SGI, IBM в AIX. В иксах в конце-концов ушли в сторону X Rendering Extension.

https://www.x.org/releases/X11R7.5/doc/graphics/dps.html#AEN12

Вот тут подробнее написано: http://dps.sourceforge.net/ Смысл такой, что очень сложная реализация всех примитивов DPS, которую надо постоянно держать на стороне X-сервера, а используются они далеко не всеми, поэтому, типа, пришли к мысли, что надо гонять только самые базовые примитивы по сети, а более сложные, которые состоят из этих базовых, реализовывать на стороне клиента в виде библиотеки. Так и получилось, что для 2D пришли в XRender. Теперь любой графический объект (например, закрашенный круг или кривая произвольной толщины) просто бьются на треугольники и трапезоиды и гонятся в таком виде уже на X-сервер, где эти все дела аппаратно ускорены. Ну и градиенты тоже, глифы, пиксманы (pictures в XRender) и композитинг. А на стороне X-клиента возникла высокоуровневая Cairo.

И еще был ряд технических проблем (с растровой графикой), которые Keith Packard описывал тогда, когда проектировали XRender. С DPS были какие-то проблемы с лицензированием и вообще с тем, будет ли Adobe в будущем вообще поддерживать этот стандарт.

http://dps.sourceforge.net/index-old.html

Да уж, как зоопарк тулкитов и сред всё усложняет. По мне так можно было бы сделать так: сформировать набор стандартных объектов gui - типа, «плоская кнопка», «градиентная кнопка», «объёмная кнопка», «нажатая кнопка», и так далее - это всё ведь несложно описать формулами (примитивами), так? Что-то вроде svg, наверное

Ну, если все сведется к картинке, то для картинок есть примитивы «Покажи картинку». Универсальный примитив, но не шибко оптимальный с точки зрения передачи по медленной сети. В RDP, кстати, есть расширение для ускорения GDI (информация старая, того времени, когда я этим поинтересовался). Насчет того, что Микрософт гонит описания интерфейсов по сети, я не знаю, а вот насчет GDI — 100%. То есть если тулкит использует стандартные операции рисования интерфейса на 2D, то RDP может ускорить это таким же механизмом, как и X11. Вот я тут прямо введение из стандарта привел. Скопирую

Смотрим документацию на Remote Desktop Protocol: Graphics Device Interface (GDI) Acceleration Extensions и читаем:

1.3 Overview

The Remote Desktop Protocol: GDI Acceleration Extension reduces the bandwidth associated with graphics remoting. The following sections provide an overview of the major components of this protocol and how bandwidth reduction is achieved.

1.3.1 Accelerated Graphics

The remoting of graphics images (see [MS-RDPBCGR] sections 2.2.9.1.1.3.1.2 and 2.2.9.1.2.1.2) is accomplished by continuously sending updated bitmap images from server to client. Even though these bitmaps may be compressed, it is still not a bandwidth-efficient mechanism to employ, especially when dealing with graphics-intensive applications that refresh regularly. The Remote Desktop Protocol: GDI Acceleration Extension aims to reduce the bandwidth associated with graphics remoting by encoding the drawing operations that produce an image instead of encoding the actual image. For example, instead of sending the bitmap image of a filled rectangle from server to client, an order to render a rectangle at coordinate (X, Y) with a given width, height, and fill color is sent to the client. The client then executes the drawing order to produce the intended graphics result. In addition to defining how to encode common drawing operations, the Remote Desktop Protocol: GDI Acceleration Extension also facilitates the use of caches to store drawing primitives such as bitmaps, color tables, and characters. The effective use of caching techniques helps to reduce wire traffic by ensuring that items used in multiple drawing operations are sent only once from server to client (retransmission of these items for use in conjunction with future drawing operations is not required after the item has been cached on the client).

«плоская кнопка», «градиентная кнопка», «объёмная кнопка», «нажатая кнопка»,

А это как раз через Render и передается (ну, почти это). то есть там есть градиенты: https://www.x.org/releases/current/doc/renderproto/renderproto.txt :

CreateSolidFill
CreateLinearGradient
CreateRadialGradient
CreateConicalGradient

Это все не картинкой передается, это команды с параметрами, а сами градиенты создаются на сервере в виде картинки либо аппаратно, если умеет карта, либо программно в pixman (заоптимизированная ассемблером библиотека рисования). Потом как бы X-клиент (тулкит) дает указания, как это все обрезать и наложить друг на друга, чтобы нарисовалась градиентная кнопка с нужной прозрачностью, смешением и т. д. Отдельно рисуются буквы на кнопке - это отдельный объект. Это всё происходит тогда, когда тулкит не рисует все и картинкой заталкивает изображение, а если используется рисование в 2D на X-сервере при помощи Render.

Ну а закругления... Это уже лишнее. Тогда на все случаи жизни команд не напасешься. Ты сильно себя ограничиваешь тогда. Да и будет ли в этом выигрыш особый? Проще картинкой закругленный уголок послать или командами рисования.

Ну а закругления... Это уже лишнее

Вот так взял и обломал)

Вот так взял и обломал)

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

Но зато нарисованная раз кнопка, если она не меняется, может оставаться на X-сервере в виде X11 pixmap и мигрировать в память GPU, где и лежать. И когда ее надо будет перерисовать, то второй раз ее слать не надо будет - тулкит дает команду в X-сервер, чтобы GPU скопировал pixmap с указанным XID в нужное место. Ну вот как бы и получается экономия на трафике. В целом-то созданные ранее пиксмапы тулкиты могут держать на X-сервере и при необходимости выводить.

А можно ли разделить тулкит на две части: высокоуровневую, работающую на клиенте. И низкоуровневую-серверную, которая будет по примитивам тулкитам рисовать интерфейс. И завернуть всё стандартным сетевым протоколом.

Ну как бы теоретически это можно, да и практически. Но только так как тулкитов много (зоопарк), то каждый тулкит должен иметь свой протокол и свою серверную часть. И все это как-то должно работать вместе. UPD: Да, и если ты окажешься где-то, где нет модуля отрисовки интерфейса GTK, например, то тогда ты не сможешь задействовать этот механизм и будет все картинками опять.

Сейчас в X11 все сделано так, что выбран некий общий знаменатель для рисования (рисованием протокол не ограничивается, он еще и об окнах, свойствах окон, их иерархии, устройства ввода, курсоры и т. д.), которым можно рисовать, композитить, текст писать. Ну. такой trade-off между простотой протокола, трафиком и архитектурной сложностью. А вообще самый общий знаменатель - это просто гонять картинки, но это неэффективно.

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