> Давай поступим так: сначала ты сдашь вторую сессию, а потом начнешь предлагать и рассуждать?

Сессию? Зачем мне второе высшее образование? :)

_Любой_ алгоритм работающий не от команды, а от пиксмапа, сдохнет уже на первой строке

Битмапом перешлется тупо весь экран. Один раз. Чтобы выполнить командой придется переслать bgpixmap + все pixmaps[], а потом еще и работу какую-то сделать. Что хуже? Помоему очевидно.

Да и какой-то дебильный пример, ей богу. Не от мира сего. Разговор вообще про удалённую работу, а это обычно подразумевает что-то вроде текстового редактора и изменение небольших участков экрана. Соответственно - изменяющиеся блоки чаще однородные, поэтому хорошо сжимаются. Какие ещё пользователь делает операции? Скроллинг? Перенос окна? Ну так отследить смещение части экрана тоже какбы вполне реально, сказав клиенту об этом парой байтов и дослав нехватающие области (тоже часто однородные). Сворачивание/разворачивание - кеширование.

Ещё раз - протоколу не нужно слать весь битмап постоянно. Нужно лишь сравнивать изображения в буфере с каким-то временным шагом. Хороший алгоритм сведёт пересылку битмапов к минимальному уровню. Что-то вроде кодирования видео с разными типами кадра. Хотя не спорю - это более ресурсоёмкая задача. Зато более универсальная.

А теперь добиваем. Я корпоративный юзер... Сижу на тонком клиенте (X-терминале). Видеокарты на сервере у меня нет

Какой-то особо бедный у вас корпоратив ))
А мне в раб.станцию ксеон воткнули (

Командно-ориентированный X11

Кто вообще сказал что битмапы отменяют команды? Для операций с ними тоже есть команды. И ещё кучу можно придумать более оптимальных, а не образца 80х. Поле для творчества программисту.

И OpenGL-ный приложения (визуализации всякие) работают только шум стоит.

Нет, ты искренне веришь, что отрисовку OpenGL иксы шлют в виде команд? xD
Да ещё и с headless сервера? xD
Да и, собственно, какой нафиг корпоратив с OpenGL? Вам шашечки или ехать?

рассказывают, что оказывается (!) у меня все неправильно

Иксы никто лично у тебя не заберёт. Катайся дальше.
Твой клинический случай лишь исключение из правил. Ориентироваться на исключения, как минимум - не адекватно.
Но не всё так плохо как ты боишься. Хотя снова - зависит от того, кто будет реализовывать и сколько у него на это будет времени.

и теперь мне надо... Купить видеокарты в сервер

Чувак, я тебя обрадую - wayland работает с буфером. А буфер может находиться и в обычной памяти. Так что аналог Driver «dummy» более чем реален.

> Если загрузить сервисы в пространство микроядра, получится микроядро без аппаратной защиты памяти, а никак не монолит.

И чем передача сообщения в пределах такого ядра отличается от вызова процедуры с передачей аргументов на куче? Тем, что сервис может быть в отдельной ядерной нити? Чем это отличается от любого многопоточного приложения?

Возможность загрузить модули драйверов…

Не только драйверов, но и расширений, например. При этом какой-нибудь synaptic-drv.so явно загружен в общее адресное пространство с libextmod.so, но тебе явно придется постараться, показывая, как они друг от друга зависят.

> Битмапом перешлется тупо весь экран. Один раз. Чтобы выполнить командой придется переслать bgpixmap + все pixmaps[], а потом еще и работу какую-то сделать. Что хуже? Помоему очевидно.

Тяжело не знать математику. 1280 * 1024 * 3 = 3932160. Тупо один раз. 4 мегабайта. Ага. «По-моему очевидно.»

Нет, ты искренне веришь, что отрисовку OpenGL иксы шлют в виде команд? xD Да ещё и с headless сервера? xD

Нет, дорогой, они их сначала рендерят программно месой со скоростью современной видеокарты, а затем отсылают, каждый кадр по 4 метра. Живи дальше в фантастическом мире, где видеоускорители не нужны по причине тотально победившего software rendering-а.

Чувак, я тебя обрадую - wayland работает с буфером. А буфер может находиться и в обычной памяти. Так что аналог Driver «dummy» более чем реален.

Ана, и рендерить в этот буфер на стороне приложения тем самым программным рендером. Жги дальше.

> Тяжело не знать математику. 1280 * 1024 * 3 = 3932160. Тупо один раз. 4 мегабайта. Ага. «По-моему очевидно.»

ну если забыть, что картинку можно пережать( а сожмется она такая до десятка-двух Кб в PNG ), то да - ситуация просто ужасная :)

Кто вообще сказал что битмапы отменяют команды?

«Команды» это rendering API. В вейланде его нет и не планируется. Всё, все твои оптимизации идут в никуда.

Какой-то особо бедный у вас корпоратив

Ты наверное будешь очень расстроен увидев вывод prtconf, в котором 16 процессоров и ни одной видеокарты. И будешь дважды расстроен, когда узнаешь что это не x86[64], и это совсем даже не железка, а лишь одна из зон на ней.

Так что аналог Driver «dummy» более чем реален.

Угу. И сколько «драйвер „dummy“» будет рендерить страничку текста с антиалиасингом?

Ориентироваться на исключения, как минимум - не адекватно.

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

> ну если забыть, что картинку можно пережать( а сожмется она такая до десятка-двух Кб в PNG )

Во-первых, ты раз в 10-20 преуменьшил размер типичного скриншота png в таком разрешении. А во-вторых, аппаратно ускоренный рендеринг мы учитываем в пункте «а потом еще и работу какую-то сделать», а затраты на упаковку-распаковку данных — не учитываем, так что ли? Чудесно.

> Во-первых, ты раз в 10-20 преуменьшил размер типичного скриншота png в таком разрешении.

может потому-что типичный скриншот не представляет собой слова «жопа», растиражированное 1000 раз на однотипном фоне?

А во-вторых, аппаратно ускоренный рендеринг мы учитываем в пункте «а потом еще и работу какую-то сделать», а затраты на упаковку-распаковку данных — не учитываем, так что ли? Чудесно.

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

> Битмапом перешлется тупо весь экран. Один раз.

А потом все плохо сжимающиеся изменения. Вместо коротких команд рисования. Сравни уже VNC, RDP и X11 в одинаковом разрешении с одной глубиной цвета на схожих задачах. Чтобы прочувствовать разницу, сделай линк помедленней, 10Мбит уже достаточно медленно, чтобы VNC тормозил.

Кто вообще сказал что битмапы отменяют команды? Для операций с ними тоже есть команды. И ещё кучу можно придумать более оптимальных

Ну вот когда придумаешь, приходи, сравним. Пока можешь попробовать доказать преимущество VNC перед RDP.

Нет, ты искренне веришь, что отрисовку OpenGL иксы шлют в виде команд?

Именно так они и делают. Естественно, нет DRI, но аппаратно ускоренный OpenGL никто не забирает.

Да ещё и с headless сервера?

С headless клиента. На X-сервер (X-терминал), который и выполняет OpenGL команды.

и теперь мне надо... Купить видеокарты в сервер

Чувак, я тебя обрадую - wayland работает с буфером. А буфер может находиться и в обычной памяти. Так что аналог Driver «dummy» более чем реален.

Нереален. Кто будет тебе ускорять рисование в этот буфер? Ты же первый от тормозов удавишься.

> И чем передача сообщения в пределах такого ядра отличается от вызова процедуры с передачей аргументов на куче? Тем, что сервис может быть в отдельной ядерной нити? Чем это отличается от любого многопоточного приложения?

В зависимости от конкретной реализации, ответы могут быть любыми. А ключевое отличие от монолитного ядра в том, что внутриядерный сервис ничем не отличается от внеядреного с точки зрения прочих сервисов и клиентов. Ничем — значит ничем. Если собрать микроядро на архитектуре без MMU, оно не перестаёт быть микроядром.

Не только драйверов, но и расширений, например. При этом какой-нибудь synaptic-drv.so явно загружен в общее адресное пространство с libextmod.so, но тебе явно придется постараться, показывая, как они друг от друга зависят.

Так значит я могу пересобрать synaptic-drv.so и libextmod.so как /usr/libexec/synaptic-drv и /usr/libexec/extmod и запустить как клиентские по отношению к икс-серверу процессы? Или всё же не могу?

я был не прав, если залить текстурой фон, то png жмет только до 100Кб с «копейками»

> Тяжело не знать математику. 1280 * 1024 * 3 = 3932160. Тупо один раз. 4 мегабайта. Ага. «По-моему очевидно.»

Не понял, один bgpixmap весит столько же. В чём смысл изречения? Да и рисуется какой-то сферический конь, не имеющий отношения к реальности. Прям как вывод полноэкранного видео.

затем отсылают, каждый кадр по 4 метра. Живи дальше в фантастическом мире

Причем тут 4МБ кадры? Тебя заклинило ? ЗАЧЕМ слать кадый кадр? :)
Ты хоть понял что я писал-то?
Даже если X каким-то чудесным образом шлёт opengl команды/контент на клиент, то это очень спорный подход, хотябы потому что клиент может оказаться «слишком тонким» :)
И вообще разговор был как-бы про RDP а не про X. К иксам пришли по аналогии. Судьба именно иксов меня мало волнует.

ну если забыть, что картинку можно пережать( а сожмется она такая до десятка-двух Кб в PNG ), то да - ситуация просто ужасная

Блииин, ну какой ты все-таки недалекий...

Хорошо, есть окно текстового процессора, документ в котором мы просто и аккуратно скроллим мышкой. Размер окна 1920x1080. Сколько ресурсов займет сравнить такую картинку, вычислить дельту, сжать ее и отправить к клиенту? Только не надо говорить про свои домыслы, проверь фактами - возьми например Istanbul, включи его на граббинг экрана и запиши в полныйй размер. А мы посмотрим на результат (использование процессора и размер файла) и вместе посмеемся над идеей пересылать битмапы.

На C2D E5200 у меня получился 0.3-1 fps, размер файла за 15 секунд был под 15 мегабайт, ага.

По факту, для работы эта методика непригодна, вообше.

> Не понял, один bgpixmap весит столько же.

Фантазия у тебя богатая, но лучше всё же читать то, на что отвечаешь: «И есть окно 1280x1024 заполненное тайлингом некоторой картинкой.»

ЗАЧЕМ слать каждый кадр?

Ты разработал магическую технологию отправки результатов работы рендера OpenGL, когда можно слать только 1 кадр в секунду, а на экране получать 60 FPS? :D Извини, но это уже просто смешно.

Даже если X каким-то чудесным образом шлёт opengl команды/контент на клиент, то это очень спорный подход, хотябы потому что клиент может оказаться «слишком тонким» :)

То есть с архитектурой иксов ты не знаком, и даже более того, не знаком с тем, что OpenGL изначально by design имеет клиент-серверную архитектуру. Так бы сразу и сказал: «предмета не знаю, но судить берусь».

> Угу. И сколько «драйвер „dummy“» будет рендерить страничку текста с антиалиасингом?

KDE4 на домашней headless файлопомойке бегает вполне шустро через RDP. Особо тормозов не наблюдаю. MS RDP сервер точно также рендерит в память и ничего, работают люди. Без акселерации и шашечек.

но тащить его на большой десктоп

Именно там он и нужен обычным пользователям, которых большинство. Максимально тонкий и лёгкий.

> возьми например Istanbul, включи его на граббинг экрана и запиши в полныйй размер. А мы посмотрим на результат (использование процессора и размер файла) и вместе посмеемся над идеей пересылать битмапы.

ты дебил и не лечишься, и это абсолютно точно, совсем недавно я через TeamViewer помогал человеку настраивать линукс - и как ни странно, что мне, что ему было __насрать__ грузился при этом на фоне процессор или нет

На C2D E5200 у меня получился 0.3-1 fps, размер файла за 15 секунд был под 15 мегабайт

теперь все ясно - ты просто неудачник с кривыми руками, потому-что такие цифры по-другому не получить

Даже если X каким-то чудесным образом шлёт opengl команды/контент на клиент

Я тебя просто пошлю сюда - Два в одном

Там на скрине квака OpenGL'ная выдает 60 FPS _по сети_. Так что ДА, В X11 OPENGL ОТДАЕТ КОМАНДЫ, А НЕ ПИКСМАПЫ. X11 очень мощная штука, просто тулкитописатели не могут ее осилить, или не хотят из-за того, что при полномасштабном использовании X11 тулкит на него сильно завяжется.

> Именно там он и нужен обычным пользователям, которых большинство. Максимально тонкий и лёгкий.

Ни единого пруфа, как обычно.

я через TeamViewer помогал человеку настраивать линукс

Ты походу настолько туп, что не способен увидеть разницы между «работать на удаленной системе» и «видеть слайд-шоу удаленного десктопа»?

> Ты разработал магическую технологию отправки результатов работы рендера OpenGL, когда можно слать только 1 кадр в секунду, а на экране получать 60 FPS?

ЗАЧЕМ нужны такие fps для РАБОТЫ?
ЗАЧЕМ нужен OpenGL для удалённой РАБОТЫ?

Мы друг друга не понимаем. Увы.

И да - если картинка более-мение статичная, фпс будет относительно неплохим и с низкой загрузкой канала. Причем одинаково, что на телефоне без 3D вообще, что на мощной рабочей станции.

> Ты походу настолько туп, что не способен увидеть разницы между «работать на удаленной системе» и «видеть слайд-шоу удаленного десктопа»?

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

ЗАЧЕМ нужны такие fps для РАБОТЫ?
ЗАЧЕМ нужен OpenGL для удалённой РАБОТЫ?

А ЗАЧЕМ ты отвечаешь на сообщения, которые не читал?

А теперь добиваем. Я корпоративный юзер. Клиент редхата. Сижу на тонком клиенте (X-терминале). Видеокарты на сервере у меня нет, а на клиенте (X-терминале) есть... И ого-го какая. Командно-ориентированный X11 летает как электровеник. И OpenGL-ный приложения (визуализации всякие) работают только шум стоит. И тут приходят вялендофилы и рассказывают, что оказывается (!) у меня все неправильно, и теперь мне надо... Купить видеокарты в сервер (в каждый) и поставить 10-гигабитную сеть, поскольку у них есть более передовая технология.

И да - если картинка более-мение статичная, фпс будет относительно неплохим и с низкой загрузкой канала.

Опять при помощи магии?

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

Ну да, верно. Никого кроме меня. Ну и еще кроме 200 юзеров в одном только филиале одной только компании с одним приложением, 400 человек в дочерней компании со вторым, еще 100 человек с третьим приложением, еще 100 примерно с четвертым... Ну и надо не забыть добавить, что филиалов под десяток (про другие я точных цифр не знаю).

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

ЗАЧЕМ нужны такие fps для РАБОТЫ?

1. Чтобы не видеть слайд-шой

2. Ты путаешь причину и следствие. 60FPS это _следствие_ командно-контектсной структуры X11 и OpenGL

Причина же в том, что на начальном этапе было сделано предположение, что ресурсы сервера дороги, ресурсы клиента дешевы, так что пусть рутиной работой занимается клиент (и его X-сервер). Вселдствие этого и получилась аккуратная - да, сейчас обросшая расширениями, но технологически все еще превосходящая платформа X11.

>Именно там он и нужен обычным пользователям, которых большинство. Максимально тонкий и лёгкий.
Для обычных пользователей есть альтернативные ОС.

> Там на скрине квака OpenGL'ная выдает 60 FPS _по сети_. Так что ДА, В X11 OPENGL ОТДАЕТ КОМАНДЫ, А НЕ ПИКСМАПЫ.

Окей, тоесть чтобы запустить кваку всеравно надо переслать все текстуры и модели на клиент? Вот так взять и переслать скажем 200МБ на клиент?
А если это не квака, а современная игра? Пересылать гигабайты? А если канал узкий? Вообще дальше интранета кто-то его тестировал?
А если клиент слабый? Вообще какой смысл тонкого клиента в данном случае? Идея том, чтобы именно сервер выполнял большую часть работы. Т.е. если даже и игра, то чтобы можно было чуть ли не с телефона зайти и проверить копает ли твой скриптованый персонаж что-то или нет. Я так думаю. Что, для этого человеку надо пол игры на телефон качать? А что будет при обрыве? Новая сессия и качать заново?

> Для обычных пользователей есть альтернативные ОС.

Шаттлворт с тобой не согласен :)

Плевал я на его мнение.

> Вот так взять и переслать скажем 200МБ на клиент?

лицоладонь.png. Второквака требует для работы 200МБ видеопамяти? Или таки нет?

переслать все текстуры и модели
модели

google: OpenGL Reference Manual, OpenGL Programming Guide. Бесполезно объяснять человеку, что вода мокрая, если он не знает значений слов «вода» и «мокрая».

> Второквака требует для работы 200МБ видеопамяти?

Мне пофиг что требует вторая квака. Это вообще не суть.

Бесполезно объяснять человеку

Тебя кто-то просил мне что-то объяснять?
Нет? Свободен!

> Вообще какой смысл тонкого клиента в данном случае?

Смысл тонкого клиента в том, что на нём крутится дисплейный сервер... и, собственно, всё. Даже жесткий диск не обязателен.

Идея том, чтобы именно сервер выполнял большую часть работы.

Верно, он её и выполняет: сервер приложений с мощным CPU гоняет приложения, а дисплейный сервер с видеокартой рисует интерфейс.

Т.е. если даже и игра, то чтобы можно было чуть ли не с телефона зайти и проверить копает ли твой скриптованый персонаж что-то или нет.

Ох, чудо. Куда именно ты собрался с телефона заходить?

> Мне пофиг что требует вторая квака. Это вообще не суть.

А что тебе суть? Требования игры к видеопамяти обычно написаны на коробке. Находится твои дисплей на том же компе, что и игра, или на другом конце земного шара — системные требования от этого не изменятся.

Тебя кто-то просил мне что-то объяснять? Нет? Свободен!

Сходи на кухню, выпей валерьянки. Нервы надо беречь.

ЦЕА?

я вижу что вы что-то путаете.. но это вне моей компетенции

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

всем кто не может\хочет помочь тестировать и писать вейланд следует воздержаться от его анализа до тех пор. такие дела

Даже если X каким-то чудесным образом шлёт opengl команды/контент на клиент, то это очень спорный подход, хотябы потому что клиент может оказаться «слишком тонким» :)

Не чудесным образом, а способом, который был изначально заложен в OpenGL. А иксы для инкапсуляции потока GL-команд используют расширение протокола GLX. Рисование командами GL действительно может оказаться гораздо более затратным в некоторых случаях, нежели передача картинок, отрендеренных на терминальном сервере установленными на ней ускорителями. Именно поэтому есть VirtualGL.

чувак отсыпь спайсва даже я так далеко в будующее не вижу..

У вас какой-то комплекс по поводу федоры?

Я с большей уверенностью могу заявить, что пока что-то не попадет в Debian Stable им лучше не пользоваться.

Я вижу вы очень толсто троллите, но это не в моей компетенции.

В учебнике русского языка ты тоже много чего не увидел.

речь шла не о пользование а о начале момента принятия решения а надо ли оно в уютном дебьяне

увы да я здесь чтобы рушить догматы(с)

\\ и моё поколение ещё не родилось, но сайрус уже здесь.

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

Практика с гномом третьим говорит о ином

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

Для тестирования новых фич есть арч и генту, почему у вас федоропроблемы в школах в мое время не учили

Вообще то арч с гентой существуют не для этого. А вот то, что на федоре RH обкатывает все новое, ни для кого не секрет, и никогда не скрывалось.

все новое для RHEL.

Все новое для RHEL чем то отличается от всего нового для остальных?

Скорость IPC микроядер на порядки выше чем в монолитных ядрах.

Сфига это?

Потому, что у других дистрибутивов другие мейнтейнеры и другие, зачастую, критерии.

Спасибо, Кэп. Но это не отменяет того, что gnome3 является новым что для федоры, что для арча, что для любого другого дистрибутива.

> Причина же в том, что на начальном этапе было сделано предположение, что ресурсы сервера дороги, ресурсы клиента дешевы, так что пусть рутиной работой занимается клиент (и его X-сервер). Вселдствие этого и получилась аккуратная - да, сейчас обросшая расширениями, но технологически все еще превосходящая платформа X11.

именно для таких случаев - дорогой сервер, мощный графический клиент - X11 технологически превосходен, аккуратен и расширяем. для всех остальных: десктоп, тонкий клиент, мобилки, игры и т.п. - оказывается слишком специфичным и мимо кассы. в этом вся проблема.

на десктопе есть свои важные особенности, которые x11 не учитывает. почему на том же железе, где квака может рендерится со скоростью 60fps, без нагрузки, при элементаром перетаскивании окон видно слайд-шоу, а элементы gui откликаются с заметной задержкой? ответ в архитектуре, которую x11 фактически навязывает для приложений, занимающихся композицией окон — им больше ничего не остается как работать с ними на уровне толстенных pixmaps. даже opengl тут не сильно помогает. вообще, до появления Xgl, ни кому в голову не приходило, что тормозная загрузка GLX_EXT_texture_from_pixmap может оказаться кому-то нужной. в играх такого изврата не было точно.

в играх важен не только максимальный fps, но минимальный latency - задержка между тем что происходит на сервере, и тем, что игрок видит у себя на мониторе. квака, рендерящаяся через x11 со скоростью 60fps, позволяет с комфортом, пожалуй, лишь смотреть демки. о поиграть речи практически не идет — лаг таков, что вас убивают раньше, чем вы видите того, кто стрелял. :) протоколы обмена данными в играх всегда учитывают lanency, а в x11 на это нет даже намёка потому, что он проектировался под другие задачи. кстати передачу звука из x11 выкинули именно по этой же причине - неконтролируемый latency, а вовсе не потому, что удаленных звук для приложений нафик не нужен.