Эксперная оценка? Получится упрощенный вариант иксов, который не могли получить из самих иксов потому что «аряяяя нам нужна обратная совместимость с говном из 80-х».
Оно конечно не помешает. Пущай будет. Но я не вижу в этом большого смысла и насущной необходимости. Вся суть вейланда в том, что приложения имеют как можно более непосредственный доступ к видеопамяти, с минимальной буферизацией и оверхедом на пути картинки от приложения к экрану. При работе через сетевую прозрачность все эти преимущества теряются.
Кстати, вот говорят, что раньше у иксов был свой гуи-фреймворк, который рисовал гуи примитивами, и из-за этого всё было очень быстро, в т.ч. и через сеть. А сейчас можно сделать такое же, только современное и невырвиглазное?
Можно, конечно. Можно взять Qt с его сигналами-слотами за основу (потому что это уже почти готовый RPC) и подвести под него сеть. Весь вопрос в том, чтобы это сделать. Это долго, трудоёмко и нафиг никому не упало.
и из-за этого всё было очень быстро, в т.ч. и через сеть.
В 1999 г я вполне успешно работал в Netscape на SUNовской машине, расположенной в Хьюстоне. Окно которого прорисовывалось средствами X-Window у меня на домашнем ПК в Питере. При этом к Сети я был подключен через самопальный dial-up на 28800 бот. Единственным условием комфортной работы было задействование модуля сжатия в X-Window, к сожалению, подробностей уже не помню, но тогда это было каким-то очередным расширением протокола X11. Помню, что его включение очень сильно улучшило отзывчивость Netscape. Единственной проблемой был исходный запуск приложения - окно несколько минут прорисовывалось, но потом довольно шустро работало.
Потому что оно битмапы/пиксмапы иконок интерфейса передавало. А потом просто кидало команды рендеринга - шрифты в иксах в то время были с клиентской стороны.
Потому что оно битмапы/пиксмапы иконок интерфейса передавало. А потом просто кидало команды рендеринга - шрифты в иксах в то время были с клиентской стороны.
Ну да. Собственно говоря, выше alexferman именно об этом и писал.
Потому что требования взаимно противоречивые. С одной стороны нужно ограничиться набором требований и заморозить их так, чтобы можно было оформить всё в протокол, обязательный к исполнению всем. С другой стороны, ты затребовал «современное и невырвиглазное». А это нельзя сделать в замороженном виде. Просто потому что современное в 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-серверов со своими шрифтами, которые никому не дают, очень разные устройства отображения. Сейчас уже смысла нет, но иногда удобно все же.
Кстати, вот говорят, что раньше у иксов был свой гуи-фреймворк, который рисовал гуи примитивами, и из-за этого всё было очень быстро, в т.ч. и через сеть.
Вообще, практически все тулкиты рисовали примитивами раньше. Шрифты - примитивы, прямоугольники (закраска областей), линии, пиксмапы на сервере были, ими оперировали. Потом, когда Render Extension появилось, то еще 2D-примитивы появились: трапезоид, треугольник, градиенты, глифы. Если установить renderer у тулкита в render, то вот такими примитивами будет рисовать.
А насчет древнего фреймфорка... Был и есть Xt (https://en.wikipedia.org/wiki/X_Toolkit_Intrinsics). На его основе реализованы Xaw, Motif и еще там кто-то был. Но рисование это все равно сводилось к графическим примитивам X-протокола. Этот фреймворк был просто для того, чтобы часть вопросов взаимодействия с иксами спрятать от тулкитов.
Если установить renderer у тулкита в render, то вот такими примитивами будет рисовать.
То есть в x11 (он так чаще называется). И можно посмотреть при помощи xtrace, что приложение гонит на X-сервер. Например, evince на GTK3, если грепнуть вывод по RENDER-Request выдает, что отрисовка идет графическими примитивами trapezoids, glyph (буковки - отдельный примитив), закраска областей и т. д. (в Render примитивов мало):
Расширение DPS (Display PostScript) было когда-то для иксов даже. И его поставляли SGI, IBM в AIX. В иксах в конце-концов ушли в сторону X Rendering Extension.
Вот тут подробнее написано: http://dps.sourceforge.net/ Смысл такой, что очень сложная реализация всех примитивов DPS, которую надо постоянно держать на стороне X-сервера, а используются они далеко не всеми, поэтому, типа, пришли к мысли, что надо гонять только самые базовые примитивы по сети, а более сложные, которые состоят из этих базовых, реализовывать на стороне клиента в виде библиотеки. Так и получилось, что для 2D пришли в XRender. Теперь любой графический объект (например, закрашенный круг или кривая произвольной толщины) просто бьются на треугольники и трапезоиды и гонятся в таком виде уже на X-сервер, где эти все дела аппаратно ускорены. Ну и градиенты тоже, глифы, пиксманы (pictures в XRender) и композитинг. А на стороне X-клиента возникла высокоуровневая Cairo.
И еще был ряд технических проблем (с растровой графикой), которые Keith Packard описывал тогда, когда проектировали XRender. С DPS были какие-то проблемы с лицензированием и вообще с тем, будет ли Adobe в будущем вообще поддерживать этот стандарт.
Да уж, как зоопарк тулкитов и сред всё усложняет. По мне так можно было бы сделать так: сформировать набор стандартных объектов gui - типа, «плоская кнопка», «градиентная кнопка», «объёмная кнопка», «нажатая кнопка», и так далее - это всё ведь несложно описать формулами (примитивами), так? Что-то вроде svg, наверное
Deleted ()
Последнее исправление: Deleted
(всего
исправлений: 1)
Ну, если все сведется к картинке, то для картинок есть примитивы «Покажи картинку». Универсальный примитив, но не шибко оптимальный с точки зрения передачи по медленной сети. В 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).
Это все не картинкой передается, это команды с параметрами, а сами градиенты создаются на сервере в виде картинки либо аппаратно, если умеет карта, либо программно в pixman (заоптимизированная ассемблером библиотека рисования). Потом как бы X-клиент (тулкит) дает указания, как это все обрезать и наложить друг на друга, чтобы нарисовалась градиентная кнопка с нужной прозрачностью, смешением и т. д. Отдельно рисуются буквы на кнопке - это отдельный объект. Это всё происходит тогда, когда тулкит не рисует все и картинкой заталкивает изображение, а если используется рисование в 2D на X-сервере при помощи Render.
Ну а закругления... Это уже лишнее. Тогда на все случаи жизни команд не напасешься. Ты сильно себя ограничиваешь тогда. Да и будет ли в этом выигрыш особый? Проще картинкой закругленный уголок послать или командами рисования.
Ну как бы а потом этим никто пользоваться не будет, так как скажут, что закругленные кнопки - это прошлый век и сейчас везде треугольный дизайн :) Так и происходит :)
Но зато нарисованная раз кнопка, если она не меняется, может оставаться на X-сервере в виде X11 pixmap и мигрировать в память GPU, где и лежать. И когда ее надо будет перерисовать, то второй раз ее слать не надо будет - тулкит дает команду в X-сервер, чтобы GPU скопировал pixmap с указанным XID в нужное место. Ну вот как бы и получается экономия на трафике. В целом-то созданные ранее пиксмапы тулкиты могут держать на X-сервере и при необходимости выводить.
А можно ли разделить тулкит на две части: высокоуровневую, работающую на клиенте. И низкоуровневую-серверную, которая будет по примитивам тулкитам рисовать интерфейс. И завернуть всё стандартным сетевым протоколом.
Ну как бы теоретически это можно, да и практически. Но только так как тулкитов много (зоопарк), то каждый тулкит должен иметь свой протокол и свою серверную часть. И все это как-то должно работать вместе. UPD: Да, и если ты окажешься где-то, где нет модуля отрисовки интерфейса GTK, например, то тогда ты не сможешь задействовать этот механизм и будет все картинками опять.
Сейчас в X11 все сделано так, что выбран некий общий знаменатель для рисования (рисованием протокол не ограничивается, он еще и об окнах, свойствах окон, их иерархии, устройства ввода, курсоры и т. д.), которым можно рисовать, композитить, текст писать. Ну. такой trade-off между простотой протокола, трафиком и архитектурной сложностью. А вообще самый общий знаменатель - это просто гонять картинки, но это неэффективно.