Chromium, как все нормальные настольные приложения, должно зависеть от тулкита, а не реализации средства графического отображения, то есть не от X11Lib и не от Wayland, а только от Gtk (или Qt).
Почитал я про Иксы и Вейланд, значит. Суть такова:
Иксовая модель предполагает, что клиент будет сообщать серверу где и какой виджет отрисовать (буквально — здесь кнопку, тут надпись, а вокруг квадратик), а самим рисованием будет заниматься уже сервер. Это, на мой взгляд, верно с точки зрения клиент-серверных технологий, ибо информации между клиентом и сервером передаётся намного меньше.
Так же, на всякий случай, X-сервер предоставляет клиентам возможность прямого вывода графики (сделано это с помощью команды «нарисуй пиксель», емнип), для таких ситуаций как отображение содержимого файлов графических изображений, например.
Однако, благодаря криворукости авторов тулкитов (Gtk, Qt, wxWidgets) с одной стороны, и криворукости авторов X-сервера (бесполезность встроенных виджетов при отсутствии полезных) с другой, вся графика оконных приложений стала отрисовываться через этот самый «навсякий случай». Сам я не видел, но говорят, что у гтк/куте даже есть собственные функции попиксельной отрисовки прямых линий, работающих в обход X-серверского функционала.
Вейланд же предлагет следующую концепцию: раз клиенты всё равно сами отрисовывают всю графику, то давайте сделаем это стандартом и нормой, выкинем всё лишнее и попутно разгоним процесс, передав его видеокарте. Не так труъшно, конечно, но лучше чем постоянная работа в «запасном режиме», которая есть сейчас.
Всё правильно понял?
(помимо этого, у Иксов довольно устаревшие представления о видеокартах, но это уже глубко железные дебри в которых я не разбираюсь)
Иксовая модель предполагает, что клиент будет сообщать серверу где и какой виджет отрисовать (буквально — здесь кнопку, тут надпись, а вокруг квадратик), а самим рисованием будет заниматься уже сервер.
Всё правильно понял?
Нифига ты не понял. Иди знакомься с матчастью повторно.
Примерно так. Лишние переключения контекста из-за взаимодействия сервера с композитором, куча всего ненужного в сервере. В вейланде композитор просто линкуется с библиотекой вейланда и они работают как единое целое. Протокол максимально упрощен - клиенты просто рисуют в своих буферах и сообщают композитору, а тот формирует общее изображение. Сетевая прозрачность на уровне вейланда - по сети будет гоняться содержимое буферов клиентов, можно даже с lossy-компрессией. А Ъ-X-like-сетевая прозрачность реализуется на уровне тулкитов.
Что не так-то? Core protocol имеет команды для рисования графических примитивов, пригодных для создания убогих виджетов, но современные тулкиты ими не пользуются, а рисуют сами в пиксмапы.
Чем отправлять человека читать документацию, мог бы просто указать, что там не виджеты, а примитивы для их рисования - буковок вышло бы примерно столько же.
Тащемта xrender — это «недоделанный растровый opengl». «Сетевая прозрачность» у вяленда и современных иксов принципиально не отличается, просто сеть находится в другом звене стека. Иксовое приложение можно нормально запустить на безголовой машине, а с вейландом херня получится: он будет программно рисовать себя, вместо того чтобы пересылать команды видеокарте дисплейного сервера. Это плохо.
чтобы даже nvidia начали свой блоб пилить в его сторону
С этим все сложно. Wayland использует KMS, в закрытых драйверах его не будет, потому что он сделан так, что драйвера с его поддержкой должны лицензироваться под GPL. Правда, есть альтернатива в виде OpenWF. Бэкенд для Wayland вроде кто-то вызывался сделать, поддержку в закрытых драйверах реализовать ничто не мешает.
Тащемта xrender — это «недоделанный растровый opengl».
Интересное сравнение. Но у opengl на стороне «сервера» есть такая уберфича, как шейдеры. Больше того, сейчас с core profile без них вообще ничего нарисовать нельзя.
Иксовое приложение можно нормально запустить на безголовой машине, а с вейландом херня получится: он будет программно рисовать себя, вместо того чтобы пересылать команды видеокарте дисплейного сервера.
Будет пересылать содержимое буферов. Буфера без локальной видеокарты рисовать можно, хотя бы программно. Интересно, нельзя ли реализовать пересылку команд видеокарте на уровне драйвера?
Звучит как «машинный код поддерживается не везде». Если есть GPU, он умеет выполнять шейдеры. Другое дело, что языки их описания развиваются вместе с железом, и компилятор GLSL видеодрайвера может не уметь компилировать шейдеры старше какой-нибудь определенной его версии.
Под «шейдерами» принято понимать программы для GPU на языках высокого уровня. ARB_vertex_program и ARB_fragment_program в общепринятом понимании шейдерами не являются.
Многие интересные приложения стали возможны благодаря этим свойствам Photon. Например, на заводе оператор с портативным компьютером, имеющим беспроводное подключение к сети, может подойти к рабочей станции и «перетащить» панель управления с ее монитора на экран портативного компьютера, а затем перейти в цех и осуществлять управление.
Бгг. Вот это, я понимаю, фича - тащить свое тело к другому терминалу, чтобы перетащить окно на свой. [/fat] Вообще, есть желание поставить QNX, посмотреть, что она такое и в самом ли деле так крута, как расписывают ее адепты. Концепция пространства событий фотона действительно интересна. Оно вообще открытое или как? Читал когда-то, что открыли и раздают для некоммерческого использования, но на http://community.qnx.com/sf/projects/qnx_source написано, что я должен быть клиентом или партнером.