После четырёх лет разработки представлен (http://lists.freedesktop.org/archives/wayland-devel/2012-Oct...) первый стабильный релиз протокола, механизма межпроцессного взаимодействия и библиотек Wayland 1.0 (http://wayland.freedesktop.org/). Одновременно выпущен релиз эталонного композитного сервера Weston 1.0 (http://cgit.freedesktop.org/wayland/weston/), развивающегося в рамках проекта Wayland.
Ключевым достижением Wayland 1.0 являться стабилизация API и протокола. Если до сих пор протокол и API находились в активной разработке и постоянно менялись, что существенно усложняло развитие приложений и построение решений на базе Wayland, то отныне разработчиками гарантируется обеспечение обратной совместимости для всех выпусков в рамках текущей ветки 1.x, что даёт зелёный свет для начала повсеместного внедрения и использования Wayland.
В ближайшее время ожидается увеличение числа продуктов для прямой работы с Wayland и проведение интеграции поддержки технологий Wayland в дистрибутивы. В частности, в состав Ubuntu 13.04 планируется включить реализацию графического окружения, построенного поверх дисплейного сервера Wayland и композитного сервера Weston. Переход на Wayland позволит обеспечить бесшовную работу единого графического режима на протяжении всех стадий работы дистрибутива, включая загрузку, вход в систему и завершение работы. Кроме того, вследствие более простой архитектуры и исключения лишней буферизации, будет достигнуто увеличение производительности вывода на экран. Выполнение классических X11-приложений будет доступно по умолчанию благодаря интеграции прослойки XWayland.Напомним, что Wayland представляет (http://wayland.freedesktop.org/architecture.html) собой протокол взаимодействия композитного сервера и работающих с ним приложений. Клиенты самостоятельно выполняют отрисовку своих окон в отдельном буфере, передавая информацию об обновлениях композитному серверу, который комбинирует содержимое буферов отдельных приложений для формирования итогового вывода с учётом возможных нюансов, таких как перекрытие окон и прозрачность. Иными словами, композитный сервер не предоставляет API для отрисовки отдельных элементов, а оперирует только с уже сформированными окнами, что позволяет избавиться от двойной буферизации при использовании высокоуровневых библиотек, таких как GTK+ и Qt, берущих на себя работу по компоновке содержимого окон.
Взаимодействие с аппаратным обеспечением, например, проведение инициализации, переключение видеорежимов (drm modesetting) и управление памятью (GEM для i915 и TTM для radeon и nouveau) графических карт, может производиться напрямую через модуль, работающий на уровне ядра, что позволяет обойтись без привилегий суперпользователя. В настоящее время поддержка прямой работы c Wayland уже реализована для библиотек Gtk3+, Qt 5, SDL, Clutter и EFL (Enlightenment Foundation Library). Для обеспечения выполнения обычных X11-приложений в окружении на базе Wayland и композитного сервера Weston развивается проект XWayland, позволяющий организовать запуск полноценного X.Org-сервера в роли клиента Wayland. Примечательно, что разработчики проекта X.Org планируют включить компонент XWayland в состав X.Org Server начиная с выпуска 1.14, который ожидается в марте 2013 года.
В рамках проекта Weston развивается один из прототипов реализации композитного сервера. Подчёркивается, что это лишь одна из реализаций (по аналогии с оконными менеджерами), так как в роли композитного сервера может выступать любой другой продукт, поддерживающий протокол Wayland. Например, в настоящее время ведётся работа по обеспечению поддержки Wayland в таких существующих композитных менеджерах для X11, как KWin и Compiz. Композитный сервер Weston может работать с использованием DRM-модуля ядра Linux, поверх X11 или поверх другого композитного сервера Wayland.
URL: http://lists.freedesktop.org/archives/wayland-devel/2012-Oct...
Новость: http://www.opennet.me/opennews/art.shtml?num=35142
А как насчет проприетарных дров для святой троицы?
> А как насчет проприетарных дров для святой троицы?Корпорации двигатели прогресса. Все уже ощущают, да? :)
> А как насчет проприетарных дров для святой троицы?Какой троицы?
Штеуд уже давно официально пилит открытые дрова.
Амд тоже по этому пути пошел, да и спеки открывает. В результате открытый radeon уже давно работает гораздо лучше проприетарщины.
А нвидия... suck, baby, suck. Ничего, с их эппловксими замашками ("юзер - лох, а лохов надо стричь") - не жалко.
>> А как насчет проприетарных дров для святой троицы?
> Какой троицы?
> Штеуд уже давно официально пилит открытые дрова.
> Амд тоже по этому пути пошел, да и спеки открывает. В результате
> открытый radeon уже давно работает гораздо лучше проприетарщины.
> А нвидия... suck, baby, suck. Ничего, с их эппловксими замашками ("юзер -
> лох, а лохов надо стричь") - не жалко.Интересно, как скоро АМД обойдет по чистой прибыли Нвидию да и вообще, станет гигантом рынка. :)
>>> А как насчет проприетарных дров для святой троицы?
>> Какой троицы?
>> Штеуд уже давно официально пилит открытые дрова.
>> Амд тоже по этому пути пошел, да и спеки открывает. В результате
>> открытый radeon уже давно работает гораздо лучше проприетарщины.
>> А нвидия... suck, baby, suck. Ничего, с их эппловксими замашками ("юзер -
>> лох, а лохов надо стричь") - не жалко.
> Интересно, как скоро АМД обойдет по чистой прибыли Нвидию да и вообще,
> станет гигантом рынка. :)Никогда. У них на это 20 лет было. Они отстали - причем навсегда. 20 лет в мире IT - вечность.
А существует ли какой нить дистрибутив для демонстрации возможностей Wayland или пока демонстрировать то особо нечего, ничего не работает?
Чувствую сейчас опять будут баталии насчет нужности сабжа:)
Появится наверное. В крайнем случае, подождать 2 недели и поставить Арч (если с тамошнего диска установочные скрипты к тому времени не выкинут).
> А существует ли какой нить дистрибутив для демонстрации возможностей Wayland
UPD: Хорошо все-таки новости до конца читать - вон там в последнем абзаце ссылка на дистрибутив :)
А если новость почитать ? Старую версию покрутить повертеть можно на Ребекке, а новую придется подождать, вейланд 1.0 только сегодня релизнулся.
Похоже новость изменили и добавили, когда читал первый раз вроде не было. Хотя может и невнимательность
Тег "не нужен" еще нужно заслужить. Проект на такой стадии может рассчитывать разве что на "бесполезен"...
> разве что на "бесполезен"...Это вы наверное о себе и своем коменте :)
http://sourceforge.net/projects/rebeccablackos/
Грядут перемены, движением верным!
Сетевая прозрачность?
Сетевая прозрачность X11 - это миф. Пробросьте на сервер через SSH-туннель иксы, и запустите в них какой-нибудь Firefox, с которого попробуйте сходить на страничку с флешем.
> сходить на страничку с флешемЗачем?
> Зачем?Затем что от сетевой прозрачности приложений ожидается возможность в том числе и чего-то такого.
> Затем что от сетевой прозрачности...В приведённом Вами примере сетевую прозрачность обеспечил ssh. Вы бы могли внутри ещё пару уровней ssh-туннелей насоздавать, тогда бы у вас сама консоль тормозить начала.
вяленый улучшит это положение и всё станет флешовать на 9600?
Он хотя бы не делает хорошую мину при плохой игре, в отличие от фанбоев иксов :)
> Он хотя бы не делает хорошую мину при плохой игре, в отличие
> от фанбоев иксов :)Правильно, раз у вас не работает, давайте зарежем прозрачность у тех, у кого работает! А чё они, в самом деле! :-)
Можно подумать, что с выходом Wayland 1.0 из иксов вырезали прозрачность сетевую.
Пользуйся иксами, кто тебе мешает-то?
> Можно подумать, что с выходом Wayland 1.0 из иксов вырезали прозрачность сетевую.Речь не о том, что вырезали, речь об эмоциональном настрое публики. Дескать, раз флешь по сети тормозит, то такая сетевая прозрачность не нужна.
А в то, что Wayland хоть как-то сменит Х, я не верю. Хотя идею ты, конечно, текущим разработчикам Х подаёшь плодотворную. Это они могут, да.
Вы у вахтера часом не спрашиваете, почему улица не подметена, а у дворника - отчего в помещении посторонний? Просто очень похоже на то, судя по вопросам...
А ты всегда тёплое с мягким путаешь? Наверху рассказывали про тормознутость иксов и как от флеша ему плохеет. При этом явно подразумевается что вяленный лучше. Так что не надо с больной головы переваливать.
> Затем что от сетевой прозрачности приложений ожидается возможность в том числе и
> чего-то такого.Ну ожидается. Ну сетевая прозрачность Х работает прямо скажем неидеально (и скорость тут - дело далеко не первое!). Но, казалось бы, раз так - её надо чинить, а не убивать.
Wayland с его битмапами не даст и такой прозрачности - все приличные протоколы гоняют примитивы, а не битмапы.
>> сходить на страничку с флешем
> Зачем?Чтобы проверить на деле трепотню о якобы "сетевой прозрачности" иксов.
> Чтобы проверить на деле трепотню о якобы "сетевой прозрачности" иксов.Они прозрачны. Если тщательно подобрать задачи, аккуратно расставить начальные условия и подставить костыли. Иначе проще пользовать какой-нибудь иной протокол.
> Они прозрачны. Если тщательно подобрать задачи, аккуратно расставить начальные условия
> и подставить костыли. Иначе проще пользовать какой-нибудь иной протокол.Ну это юношеский максимализм играет - "так не доставайся же ты никому". Может быть уйдёт с возрастом и опытом.
А в чём проблема? Сетевая прозрачность из-за флэша сразу исчезла?
> А в чём проблема? Сетевая прозрачность из-за флэша сразу исчезла?Очень сильно тормозит. Вообще, сетевая прозрачность в Х крайне далека от идеала из-за того, что библиотеки Qt/Gtk не умеют пользоваться ресурсами Х, отрисовывают шрифты на стороне клиента, а не сервера (дело libXft, которую создал писатель руками Кейт Паккард, активно агитирующий за Wayland).
Так вы утверждаете, что флеш в Firefox по ssh тормозит исключительно из-за того, что Qt/Gtk отрисовывают шрифты на стороне клиента?
> Так вы утверждаете, что флеш в Firefox по ssh тормозит исключительно из-за того, что Qt/Gtk отрисовывают шрифты на стороне клиента?Нет, я не утверждаю этого.
Сетевая прозрачность - это не только скорость, но ещё и качество прорисовки/вписанности удалённых приложений в десктоп пользователя. Из-за того, что шрифты отрисовываются на стороне X-клиента, а не X-сервера, я вижу не те шрифты, которые установил я на своём десктопе, а те шрифты, что установлены админом удалённой машины. В результате, удалённое приложение выглядит не совсем так, как установленное на моём десктопе.
Это, конечно, значительно лучше, чем VNC, где удалённые приложения показываются вообще внутри окна VNC, но хуже чем идеал.
----------------------------------------------
А сетевые тормоза происходят из-за того, что вместо нормального альфа-канала в X был добавлен уродский костыль XRender. В результате, библиотеки Gtk/Qt не посылают по сети свои примитивы, а шлют разложения их на трапеции. См. картинку http://habrastorage.org/storage2/355/655/4e0/3556554e020781a... из статьи http://habrahabr.ru/post/148954/А по-хорошему, современная библиотека отрисовки типа Cairo, которая умеет хорошо рисовать шрифты, альфа-канал и т.д., должна быть просто встроена в X-сервер. Тогда сетевой трафик Хов будет просто мизерным по сравнению с тем же VNC и т.д.
> Сетевая прозрачность - это не только скорость, но ещё и качество прорисовки/вписанности
> удалённых приложений в десктоп пользователя. Из-за того, что шрифты отрисовываются на
> стороне X-клиента, а не X-сервера, я вижу не те шрифты, которые
> установил я на своём десктопе, а те шрифты, что установлены админом
> удалённой машины. В результате, удалённое приложение выглядит не совсем так, как
> установленное на моём десктопе.Зато это приложение везде выглядит _одинаково_ независимо от шрифтов которые вы тут себе понаставили. Вообще-то фича именно в этом, а не в подборе цвета фона под вашу радужку.
Ну и я так и не понял что случается с сетевой прозрачностью? Он исчезает от флеша?
Звиняйте бред я написал. Шрифты видны совершенно локальные.
> Зато это приложение везде выглядит _одинаково_ независимо от шрифтов которые вы тут
> себе понаставили.Приложение как раз не должно выглядеть "везде _одинаково_". То есть, одинаково на всех Х-терминалах. Наоборот, оно должно брать настройки шрифтов, цветов и т.д. с Х-терминала и показываться так, чтобы на Х-терминале оно было "как родное".
> Ну и я так и не понял что случается с сетевой прозрачностью?
> Он исчезает от флеша?Сетевой прозрачности на флеше на медленных сетях нет, т.к. если вы его запустите локально, вы увидите мультик, а удалённо - слайд-шоу. То есть, картинка с локальной программы Флеш и с удалённой будут разными. Это означает отсутствие сетевой прозрачности.
А у Х с Математикой, если закрыть глаза на шрифты, сетевая прозрачность почти идеальная - удалённая программа неотличима от локальной.
И что с этого? Это как-то мешает сетевой прозрачности?
> И что с этого? Это как-то мешает сетевой прозрачности?Конечно, мешает.
Вот у меня на ноуте Windows 7 с Xming. Я запускаю Математику на удалённой Linux машине с выводом на ноут и Математику на самом ноуте. Вижу совершенно разные шрифты. Почему? Из-за того, что Qt4, которая используется в Математике не умеет нормально работать с серверными шрифтами, а пытается всё отрисовать у себя (на Linux машине).
В идеальной же ситуации, эти две Математики должны быть неотличимы - зачем мне настраивать шрифты на двух машинах? Должно быть достаточно настроить их на той системе, где идёт вывод на экран.
> которая используется в Математике не умеет нормально работать с серверными шрифтами,
> а пытается всё отрисовать у себя (на Linux машине).Потому что такие задачи нужны полутора землекопам. И вот что-что а заботиться о удобстве таких граждан явно не первоочередная задача разработчиков графической подсистемы. Во первых, такие и сами позаботиться о своем заду в состоянии, а во вторых - на любой вентилятор все-равно найдется свой хитрый субъект с ломом, которого что-то не устроит и который по этому поводу лом в вентилятор воткнет.
То-есть, графическая система прежде всего должна хорошо работать локально хотя-бы. А сеть - знаете что такое "приоритет фич"? Это когда осетра урезают до того что реально можно сделать за разумное время. Вот то что вы хотите - это блажь, понты и навороты. Это не первый приоритет.
> И вот что-что а заботиться о удобстве таких граждан явно не первоочередная задача разработчиков графической подсистемы.Вот именно по этой причине мы и сидим в такой попе с Х-ами. :-) А Wayland пытается вбуриться ещё глубже с его Client-Side-Decorations. ;-)
> Вот именно по этой причине мы и сидим в такой попеБоюсь, у меня для вас плохие новости, сэр. Нет, вовсе не потому что я вас не люблю или ненавижу сетевую прозрачность. Это не так. Просто потому что я выступаю Капитаном и декларирую очевидные вещи. Которые состоят в том что озвученный вами функционал вообще малопопулярен и нужен сильно некоторым господам. А вот его реализация очень даже может замедлять работу многих иных фич, особенно когда это сделано как в иксах, когда делается довольно много лищних действий в месте где потенциально огроменный поток данных на данный момент может быть.
Намного большему количеству пользователей (и разработчиков, так или иначе) надо чтобы оно хорошо работало локально прежде всего. Стоит ли удивляться что они роют землю в именно этом направлении? Wayland - это именно оно. Вполне логичное направление. И лично мне как пользователю инициатива вполне симпатична. Для меня перфоманс локальной графической подсистемы многократно интереснее сетевых прозрачностей и прочего добра. Которое худо-бедно реализуется и иными протоколами если приспичило. ИМХО прежде всего должны хорошо работать наиболее востребованные и базовые фичи, а не какая-то экзотика, используемая 0.1% пользователей. Прокатывать 99.9% юзерей в пользу 0.1% - это хороший способ совсем утопить проект, так что на него положат и юзеры, а потом и разработчики. Все-таки разработчик без пользователей - это как музыкант без слушателей. А если вы играете так что с души воротит, но за полчаса мучений 2 минуты приятного звука - не удивляйтесь что на ваш концерт мало кто придет.
Боюсь для тебя плохие новости. Зайди в такую же тему на ЛОРе. Там анонимус с гиклесом раскатали любителей вяленого. Они могут только пузыри пускать и рожу кирпичом делать. Там и про отличную скорость вяленого и про меньше выполняемых действий по сравнению с иксами. И про прочие радости.
Ах да. Директфб был давным давно, и что-то потуг всё на него переписать не было. Анонимус с ЛОРа доставил http://youtu.be/xZ_YieaGDBM . А кто-то всё куличики лепит.
какой маразм. я вас туканов в каждой ветке про ненужность удалённых приложений буду кормить. сейчас просто вагон решений и народ активно лезет в сторону доставки приложений на рабочее место. используют виртуальное окружение от цитриксов, вмварей. а такие как ты только могут сидеть на локалхосте, жаловаться на тиринг и рассказывать " такие задачи нужны полутора землекопам"
> на тиринг и рассказывать " такие задачи нужны полутора землекопам"Иди расскажи Васе Пупкину которому кроме вконтактов да ютубов нифига не надо о том как ему надо цытриксы и вмвари.
Сколько васей пупкиных наберётся среди любителей вконтактика и линуха? А у васи пупкина кризис пойдёт на этом вашем линухе на вяленом? Ааа, это тоже надо полторам землекопам.
Сколько васей пупкиных наберётся среди любителей вконтактика и линуха?
> Лимонов двадцать как минимум - чуть менее, чем вся аудитория Убунты, прости Господи.
Извините, что поторопился отправить, не проверив... Мысленно переставьте знак цитаты вверх.
> Лимонов двадцать как минимум - чуть менее, чем вся аудитория УбунтыО да. Оказывается линух то юзается для вконтактиков в немерянных объёмах. И статистика есть? Расскажи почему у васи пупкина окошко будет тормозить при перетаскивании больше чем в иксах.
Кстати, я не увидел ответ на вопрос нужен ли васе кризис. И как тут поможет вяленый.
Омские линуксоиды так делают. Правда без флеша. И норм.
> Сетевая прозрачность?Эталонная провокация, достойная для занесения в палату мер и весов.
Это что, вот когда они додумаются спрашивать "а почему вайленд такой тормозной заикающийся как буде то у меня не i7 а P2 266 MHz", и так на самом деле будет первые года 2, вот это будет провокация.
Лично я не додумаюсь. У меня хватает соображалки на понимание, что свежие ПО на то и свежие, что не дошлифованное, и лучше поучавствовать в этой шлифовке, чем тупо материться.
А хомячок какой-нибудь на Wayland не перейдёт — не поймёт как. В убунтологических хомячков не надо пальцем показывать — они не переходят, их переводят. А по сему именно хомячки-то там сквозь баги любимой оси могут и не заметить недоработок Wayland'a.P.S. Пока что я могу всю вашу фразу в кавычках написать про X11 и без сарказмов, ибо этому продукту уже 25 лет вроде, пора бы уже было допилить.
У них в планах значится.
> По сети передаются только изменившиеся элементы окон, изменения вычисляются на уровне битмапов и передаются с использованием протокола похожего на VNC.Вперед в прошлое!
В прошлое или в будущее - пофиг. Главное чтобы работало. И работало хотя бы ... не ... геморрно.Почему то при всем "удобстве" Х-ов активно используются VNC и NX. Хотя будь Х реально удобным ни VNC ни NX даже не появились бы.
ЗЫ и все в сослогательном наклонении.
> Почему то при всем "удобстве" Х-ов активно используются VNC и NX. Хотя
> будь Х реально удобным ни VNC ни NX даже не появились
> бы.Ваша правда, но отчасти. VNC обеспечивает интероперабельность с Windows, поэтому VNC появился бы. Х, всё-таки, были разработаны для серьёзных систем, типа Unix/VMS, а не для машинок для секретуток, которыми были в то время персоналки под управлением ОС от Microsoft. ;-)
Но Х, тем не менее, удобнее VNC, т.к. позволяет встроить окно удалённой программы в систему, как родное. Условно, конечно, из-за всяких поделий, внесённых "командой Х, ратующей за Wayland", типа Xft.
> Почему то при всем "удобстве" Х-ов активно используются VNC и NX.Потому что называя вещи своими именами, иксы и их протокол относительно современных реалий оставляют желать много лучшего. Это еще очень вежливо и политкорректно сказано.
Коротко: +1
> Вперед в прошлое!Назад в будущее!
>> По сети передаются только изменившиеся элементы окон, изменения вычисляются на уровне битмапов и передаются с использованием протокола похожего на VNC.
> Вперед в прошлое!Конкретно в данном случае - в настоящее. "Сетевая прозрачность" иксов с тулкитами работает точно так же, а приложениями на чистом xlib, ввиду их отсутствия, можно пренебречь.
как его на ubuntu поставить вместо иксов?
https://wiki.ubuntu.com/Wayland
благодарю, до рф пока дойдет эта абракадабра в понятном виде сто лет пройдет деревня че кустаринчество процветает во всю водку крутят в гаражах, дольщиков забывают в список квартиирантов вписать и т.д. американцы молодцы в этом плане
Хорошо новость написана, видно, что с любовью.
Любовь это хорошо.
почему любовь и почему это хорошо?
> почему любовь и почему это хорошо?Потому что быстрые и легкие графические подсистемы - это хорошо. Это то чего лично я жду. И мне никуда не уперлась сетевая прозрачность в том виде каком она в иксах. Да, я не гоняю никаких математик на ремотных машинах. А для чего-то сверх того, например, с ремотной машины десктоп на ноут прокинуть, через тощий 3G/GPRS - оно работает более чем отвратительно, так что приходится брать более другие протоколы типа vnc/rdp.
> Потому что быстрые и легкие графические подсистемы - это хорошо.К вашим услугам WindowMaker/i3/awesome/xmonad/AfterStep/E16/Openbox/IceWM/Xfce и т.д., и т.п. Что характерно, работают уже сейчас.
> К вашим услугам WindowMaker/i3/awesome/xmonad/AfterStep/E16/Openbox/IceWM/Xfce и
> т.д., и т.п. Что характерно, работают уже сейчас.Есть только одна проблема: тормозной вывод графики через иксы в всех(?) перечисленных никуда не девается.
... и иксовый протокол по сети без докостыливания лучше работать не начинает. Мне в таком виде это не больно нравится. Хреново когда иксовый процесс жрет более чем прогармма его вызывающая. System-wide bottleneck - это плохо.
> Есть только одна проблема: тормозной вывод графики через иксы в всех(?) перечисленных
> никуда не девается.Я так понял, что вам Х мешают так, что кушать не можете.
WindowMaker и i3 на Pentium M/Centrino (8 лет машинке) работают мгновенно - глазом не заметны никакие переключения и прорисовки.
> WindowMaker и i3 на Pentium M/Centrino (8 лет машинке) работают мгновенно -
> глазом не заметны никакие переключения и прорисовки.Заметьте, я нигде и не жаловался на тормоза операций с окнами. Я жаловался на то что многие типовые действия апликух могут вызывать некислое выжирание ресурсов иксами и/или быть неоправданно тормозными. Казалось бы что может быть проще чем вывалить большой битмап? Массив сплюнуть не велика наука. Тем паче у современного хардвара есть ништяки типа DMA и GPU с приличным объемом мозгов. Казалось бы - уж и тормозить негде. Ан нет, оказывается всю эту круть вполне можно тормознуть. Достаточно неудачные концепции привинтить.
> Достаточно неудачные концепции привинтить.Это на любом графическом движке такое. На тех же Windows/MacOSX есть неудачные способы работы с графикой, подвешивающие систему.
> способы работы с графикой, подвешивающие систему.Есть. Но утверждать что так и надо - то же самое что втирать что win95 где программа может узурпировать проц и вырубить переключение задач - хорошая система.
> Есть. Но утверждать что так и надо - то же самое что
> втирать что win95 где программа может узурпировать проц и вырубить переключение
> задач - хорошая система.Нет, так не надо. Но просто не стоит орать, что Х - особомерзкая дрянь, когда у других систем всё обстоит примерно также. Проблемы у Х есть, но они не настолько фатальны, чтобы их обменивать на минусы W.
Я, как вы знаете, всеми руками за то, чтобы Х11 заменить на лучшую систему. Но эта система должна быть лучше по всем направлениям, а не по части. Иначе какой в ней смысл?
Графическая подсистема != Window Manager
> Графическая подсистема != Window ManagerДа, WM - это часть графической подсистемы, а не вся целиком. Но оптимизировать-то нужно самую жрущую часть, не так ли? А это именно KDE/Gnome. ;-)
> KDE/Gnome. ;-)У меня вообще XFCE. Это не отменяет возможности словить приличную нагрузку на иксы от иных процессов. Некоторые на первый взгляд безобидные программы вообще вызывают у иксов дикий клин. Скажем безобидная программа для рендеринга карт и GPS треков в иксах проводит в 2 раза больше времени чем в самой себе. Пи...ц, простите.
Эта нагрузка, скорее всего, никуда не денется - просто жрать процессор будет сама программа. Можно и наоборот - сунуть в иксы мощный движок отрисовки и они будут есть ещё больше, а программа-клиент - меньше. В общем, такие вещи надо по общему cpu load сравнивать. Кстати, собственно бенчмарков Вейланда в этом плане и не видно...
> В общем, такие вещи надо по общему cpu load сравнивать.Нет, извините, сравнивать надо по деструктивности последствий. Если тупит 1 конкретная программа - да мне похрен! Шедулер времени цпу в мало-мальски вменяемой современной ОС как-нибудь отмахается и проблем не будет. А вот если некая программа может поставить раком всяю графическую систему - это уже вызывает нехилый дискомфорт.
> А вот если некая программа может поставить раком всяю графическую систему - это уже
> вызывает нехилый дискомфорт.У меня такое было лишь один раз. И я в подобной ситуации запускал эту программу в отдельных Х - xinit -- :1 `type -p ...`. Такая ситуация, конечно, неприятна, но встречается, к счастью, редко.
>> А вот если некая программа может поставить раком всяю графическую систему - это уже
>> вызывает нехилый дискомфорт.
> У меня такое было лишь один раз. И я в подобной ситуации
> запускал эту программу в отдельных Х - xinit -- :1 `type
> -p ...`. Такая ситуация, конечно, неприятна, но встречается, к счастью, редко.Опять таки анонимус с ЛОРа доставляет. Хоть оттуда избранное в статью собирай.
---
Есть такая эпическая история — однажды вейландовцы задумались, что делать с подвисшими прогами? В иксах декорации окон не зависят от приложения, даже висячее окно можно переместить, свернуть, развернуть... А в вейланде каждая прога рисует свои декорации, и если она виснет, виснет и все окно, ни перетащить ни ресайзить его нельзя. Что делать? Вейландовцы прикрутили костыль — любое окно в вейланде перетаскивается по Win+LeftClick в любой части окна. И эти люди будут рассказывать нам про костыли в иксах?
---
> Скажем безобидная программа для рендеринга карт
> и GPS треков в иксах проводит в 2 раза больше времени
> чем в самой себе. Пи...ц, простите.Такое говно есть под любую оконную систему.
> Такое гoвно есть под любую оконную систему.Под остальные его такое делать куда сложнее и разработчики графических систем как ни странно стараются чинить откровенные факапы. Даже в винде наиболее крутые проблемы позволяющие свалить GDI на лопатки мизинцем - чинят слегка. Не всегда и не везде, но такой вектор тяги - есть. Потому что юзерам не нравится когда у них графика встает колом и/или все дико тормозит на ровном месте. Они за это резонно считают систему отстоем. Вполне заслуженно, btw.
> Под остальные его такое делать куда сложнее и разработчики графических систем как
> ни странно стараются чинить откровенные факапы.Подо всё можно сделать программу, которая будет вставать раком/ставить систему раком не делая почти ничего.
Как только вы делаете какую-то систему, у неё неизбежно возникают ограничения. Это закон жизни.
> Даже в винде наиболее крутые проблемы позволяющие свалить GDI на лопатки мизинцем - чинят слегка.
В виндах графикой занимаются очень серьёзные люди. Если бы не ограничения на тотальную поддержку устаревших программ, там было бы значительно лучше, чем сейчас. См., к примеру, RDP, который "слизан" с X Window System и работает быстрее.
Другое дело, что эти виндовские люди как-то умудряются сделать всё крайне неудобно. Причём просто всё.
> Не всегда и не везде, но такой вектор тяги - есть. Потому
> что юзерам не нравится когда у них графика встает колом и/или
> все дико тормозит на ровном месте. Они за это резонно считают
> систему отстоем. Вполне заслуженно, btw.Извините, но система флеш+браузер+Х состоит из 3-х компонент. Почему говном нужно считать именно Х, когда mplayer легко проигрывает видео в тех же условиях, хоть убей, непонятно.
Опять думать и искать аналог xorg.conf для добавления метамодов к NVIDIA...
Плак-плак.// Юзер ATI.
Ждем бенчмарков.
Вот тоже интересно. Действительно ощутимый прирост производительности.. Или все по мелочи..
Самое интересное, что бенчмарки штука довольно бессмысленная без корректной интерпретации:
http://blog.martin-graesslin.com/blog/2012/09/the-relevance-.../
В десктопном софте - безусловно. Есть некоторый порог отзывчивости интерфейса, если он преодолён, то дальше улучшать скорость бессмысленно.
Ну, тут дело скользкое. Допустим, обычно фигурирует как приемлемая задержка 0.25 секунды, при этом пофакту её отличие от 0.1 видит любой, а некоторые при 0.25 уже пытаются запулить техникой в стену.
> то дальше улучшать скорость бессмысленно.Есть еще нагрузка на CPU и скорость вентилятора и/или потребление батареи. Поэтому чем меньше нагрузка на проц - тем лучше. То-есть, если некая программа будет регулярно клинить проц на четверть секунды - юзер это может и не заметит особо. А вот взрев вентилятора на проце ему не понравится.
> Самое интересное, что бенчмарки штука довольно бессмысленная без корректной интерпретации:
> http://blog.martin-graesslin.com/blog/2012/09/the-relevance-.../любая информация бессмысленна без должной интерпретации
0.0%
3d-приложения обращаются напрямую к железу, иначе всё было бы оооооооооочень медленно.
> 3d-приложения обращаются напрямую к железу,Кто вам эту глупость сказал? Они дергают OpenGL или какие там еще вызовы, а вот оно уже там дальше разбирается как это железу скормить.
Вы вообще представляете себе что прямой доступ к железу может? Например можно попросить железку сделать DMA в память/из памяти. На системе без IOMMU таким манером любая программа могла бы заапгрейдиться в правах до по сути кернелмода. Ну а чо, доступ в оперативку с правами оборудования - есть. Можно хоть кернел в памяти запатчить.
А кому-нибудь попадалось описание полного стека, который они предлагают на замену иксам? Там вообще кто-то цельную конструкцию этого стека в голове держит?
> А кому-нибудь попадалось описание полного стека, который они предлагают на замену иксам?Думаю, что такого просто нет.
Ну, что-то зреет, но что не дошло до попытки всё это формально описать - грустно.
> Ну, что-то зреет, но что не дошло до попытки всё это формально
> описать - грустно.Да там весь подход - "чё тут думать, трясти надо". Поэтому максимум, что будет - это летописи приделывания костылей. Ну типа той библиотеки, что должна отрисовывать заголовок.
Правильно-то как делать:
1. Выяснить, какие есть проблемы и решения.
2. Ограничить класс устройств, на которых работает система, класс проблем, которые она решает.
3. Написать ТЗ.
4. Нарисовать архитектуру системы.
5. Выпиливать лобзиком.
Как вы понимаете, всё сделано в абсолютно противоположном порядке.
> Как вы понимаете, всё сделано в абсолютно противоположном порядке.Просто потому что они решили не строить очередной титаник по правильной архитектуре а просто решить одну конкретную проблему. Злую и всех доставшую. А именно тормозутость иксов и вывода через них графики.
> Просто потому что они решили не строить очередной титаник по правильной архитектуре
> а просто решить одну конкретную проблему. Злую и всех доставшую. А
> именно тормозутость иксов и вывода через них графики.Правильно, заради убирания тиринга (кстати, где он?) порушим всё нахрен. :-) Ну не смешно, а?
Если вас так достал мифический тиринг, ну запустите mplayer с выводом в SVGAlib - оно уже на ET6000 и Athlon 900Mhz не тормозило.
> Правильно, заради убирания тиринга (кстати, где он?) порушим всё нахрен. :-)За ради
1) Убирания тиринга.
2) Убирания жрача проца в неадекватном объеме.
3) Вывода графики с потребным потреблением ресурсов.> Ну не смешно, а?
Ни капли. Современный мир подразумевает достаточно быстрые 2D операции. Ну там например анимации и видео в браузере. И не то чтобы оно в иксах как-то так хорошо работает стандартными методами. В вэйланде при куче минусов есть коронный плюс: в нем тормозить нечему :)
> Если вас так достал мифический тиринг, ну запустите mplayer с выводом в
> SVGAlib - оно уже на ET6000 и Athlon 900Mhz не тормозило.Это все прекрасно но кроме плееров есть еще браузеры, игры, софт для анимации и рисования и прочая, желающее быстрое 2D без особых проблем.
> За ради
> 1) Убирания тиринга.
> 2) Убирания жрача проца в неадекватном объеме.
> 3) Вывода графики с потребным потреблением ресурсов.Последние 2 пункта (первого я никогда не видел вживую) убираются переходом с KDE/Gnome на любой другой WM. Эффективность такого решения дикая!
> В вэйланде при куче минусов есть коронный плюс: в нем тормозить нечему :)
Вы понимаете, что новая система по сравнению со старой минусов иметь не должна? Иначе какой смысл менять шило на мыло?
> KDE/Gnome на любой другой WM. Эффективность такого решения дикая!Да я как-то пробовал и XFCE и прочих. Они совершенно не мешают иксовому процессу жрать CPU при активном выводе графики, особенно если нечто типа анимации и большое.
>> В вэйланде при куче минусов есть коронный плюс: в нем тормозить нечему :)
> Вы понимаете, что новая система по сравнению со старой минусов иметь не
> должна? Иначе какой смысл менять шило на мыло?Я понимаю что:
1) В этом мире никто никому ничего не должен. Пора бы это уже усвоить наконец.
2) Идеализм все-таки идет нафиг - непрактичная хрень.
3) Любое решение будет tradeoff-ом в силу неидеальности мира.
4) Сильно идеализированные велосипеды хорошо ездят только по сферической поверхности в вакууме. Которую сложновато обеспечивать на всей протяженности реального маршрута.
> Я понимаю что:
> 1) В этом мире никто никому ничего не должен. Пора бы это
> уже усвоить наконец.
> 2) Идеализм все-таки идет нафиг - непрактичная хрень.
> 3) Любое решение будет tradeoff-ом в силу неидеальности мира.
> 4) Сильно идеализированные велосипеды хорошо ездят только по сферической поверхности в
> вакууме. Которую сложновато обеспечивать на всей протяженности реального маршрута.Это вы к чему так патетически высказываетесь? :-)
> Это вы к чему так патетически высказываетесь? :-)Намекаю на то что концептуально иксы ничего так, а вот реально работают довольно хреноватенько по современным меркам. Если посмотреть вокруг то можно заметить что все кому надо быстрый вывод графики и красивые эффекты - повально оставляют иксы за бортом в пользу opengl и либ вокруг него, например.
> Намекаю на то что концептуально иксы ничего так, а вот реально работают
> довольно хреноватенько по современным меркам.Надо детально разбираться в чём дело, а не орать - "этого не отмыть, будем рожать нового".
Если непонятно, в чём именно проблемы в Х, почему будет понятно, как их избежать в W? И как не понаделать новых проблем.
> Надо детально разбираться в чём дело, а не орать - "этого не
> отмыть, будем рожать нового".ИМХО дело в том что оно круто задумано но совершенно не стыкуется с современными реалиями. А у желающих попробовать отмыть никто это право не отменяет. А эти кажется решили юзать комбинированную стратегию - отмыть это насколько отмывается и сделать замену которая возможно будет летать лучше. Да, в современных реалиях апликухам надо по сути тупой и быстрый фреймбуфер + opengl. Звчучит ссыкотно, но если посмотреть на софт вокруг...
> Если непонятно, в чём именно проблемы в Х, почему будет понятно, как
> их избежать в W? И как не понаделать новых проблем.Ну вот как минимум наиболее анноящей лично меня проблемы они явно смогут избежать. Там будет нечему тормозить и жрать ресурсы оптом. А сетевой прозрачностью от именно иксов я и не пользуюсь, т.к. не вижу полезных мне юзкейсов для настолько отвратной реализации для именно этого протокола.
> ИМХО дело в том что оно круто задумано но совершенно не стыкуется
> с современными реалиями.В каком месте? А в каком стыкуется? - где точные и детальные ответы на эти вопросы?
Прежде чем строить новую систему, нужно выяснить, в чём проблема у старой. Иначе есть неплохие шансы пройтись по граблям дважды.
> А эти кажется решили юзать комбинированную стратегию - отмыть
> это насколько отмывается и сделать замену которая возможно будет летать лучше.Мы видим подход, в котором нет подробного анализа проблем и достижений Х. В результате, получаем, что предыдущий 25-ти летний опыт граф. систем под UNIX оказывается выброшен в помойку.
А это не может пройти безнаказанно. :-)
>> Если непонятно, в чём именно проблемы в Х, почему будет понятно, как
>> их избежать в W? И как не понаделать новых проблем.
> Ну вот как минимум наиболее анноящей лично меня проблемы они явно смогут
> избежать. Там будет нечему тормозить и жрать ресурсы оптом.Какой ценой? Если вы комп выключите, он тоже не будет жрать ресурсы.
> А сетевой прозрачностью от именно иксов я и не пользуюсь, т.к. не вижу
> полезных мне юзкейсов для настолько отвратной реализации для именно этого протокола.Отсутствие сетевой прозрачности - это фигня, а не проблема. Вот Client-Side-Decorations, это действительно проблема.
> В каком месте? А в каком стыкуется? - где точные и детальные ответы на эти вопросы?Где, где... у капиталистов в фразе "спрос рождает предложение". На нечто работающее как иксы спрос не будет ломовым.
> Прежде чем строить новую систему, нужно выяснить, в чём проблема у старой.
> Иначе есть неплохие шансы пройтись по граблям дважды.Основные проблемы иксов - это совершенно непотребная скорость работы. По поводу чего вообще все graphic-intensive приложения имеют свойство работать там медленнее чем в других системах при прочих равных. А вот это ай-яй-яй. Туда же и тиринг всякий. Никто не любит графическую систему которая тормозит и тирингует. Это эпикфэйл при выполнении прямейших обязанностей.
>> это насколько отмывается и сделать замену которая возможно будет летать лучше.
> Мы видим подход, в котором нет подробного анализа проблем и достижений Х.Да, граждане просто ломанулись в лоб рубиться с наиболее доставшей проблемой иксов
> В результате, получаем, что предыдущий 25-ти летний опыт граф. систем под
> UNIX оказывается выброшен в помойку.Пока-что не выброшен. Но имхо иксы туда очень напрашиваются для большинства юзеров и применений. И к этому все и придет если ничего не менять. Заодно потопит и системы полагающиеся на это за собой. Линуксоиды не хотят тонуть как куча древних юниксов и прочих BSD - вот и трепыхаются.
> А это не может пройти безнаказанно. :-)
Любое решение - tradeoff. Вопрос в том чем жертвуем и что выигрываем. Да, в у вэйланда совсем иные приоритеты и цели. Намного более приземленные и менее высокопарные. Это лишь быстрая графика локально. Подстилка под то что уже есть, чтобы оно работало лучше. Прозаично и скучно? Зато это как раз то что и нужно почти всем от графической подсистемы.
>> Ну вот как минимум наиболее анноящей лично меня проблемы они явно смогут
>> избежать. Там будет нечему тормозить и жрать ресурсы оптом.
> Какой ценой?Для лично меня - нулевой. То-есть, декорации окон и виджеты хуже чем сейчас есть рендериться не станут. А вот скорость возрастет. В каком месте я что-то проигрываю в этой схеме?
>> А сетевой прозрачностью от именно иксов я и не пользуюсь, т.к. не вижу
>> полезных мне юзкейсов для настолько отвратной реализации для именно этого протокола.
> Отсутствие сетевой прозрачности - это фигня, а не проблема.
> Вот Client-Side-Decorations, это действительно проблема.С ней живут и ничего, работает. В цивильных дистрах все еще и подогнано так что комар носа не подточит. И вот что-что а темку контролов для пары тулкитов подогнать в 100500 раз проще чем выписывать идеализированную монстряку. Как-то так все в этом мире и работает: подлатать по месту проще чем сделать заново с нуля по правильному.
Гражданин, тебе уже прописали ссылочку на ЛОР, для поправления здоровья.
Вот тебе оттуда про скорость.
---
> (в иксах композитинг идёт в два шага, в вейланде в один).А? В иксах композитинг для приложения не заметен вообще. Можно сказать, что он идет в ноль шагов. Все работает одинаково и универсально, приложение рисует свое окно и даже не знает, есть там композитный менеджер или нет.
В вейланде все хуже. Я знаю в нем два способа нарисовать окно. Первый — через дескриптор внешнего буфера. Приложение рисует окно в собственном буфере, общаясь напрямую с видеокартой. Когда оно закончило рисовать, оно передает дескриптор буфера композитору. Затем выделяет следующий буфер и рисует дальше. Получается тройная буферизация: один буфер у приложения, один у композитора и еще один сейчас передается от приложения к композитору (на самом деле их больше, потому что передаваться могут частичные буферы). Это считается за сколько шагов? Три?
Второй способ — SHM. Он в вейланде появился первым, и наверное, является основным для большинства приложений/тулкитов, поэтому их отрисовка в вейланде так тормозит. Даже в иксах Shm считается устаревшим, потому что его приходится в битмапном виде гонять туда сюда в память видеокарты и обратно. Шагов получается еще больше. Плюс это жрет в 3 раза больше памяти. Но, увы, в вейланде выбор не велик.
> Приложения, выводящие много графики в реальном времени, будут тратить меньше времени на общение с графической подсистемой.
Пока что все с точностью до наоборот. Перемещение и изменение размера окон под вейландом жутко тормозит по сравнению с иксами. Даже родные wayland gears жрут 180% CPU, но показывают 56 FPS, в то время как glxgears на той же машине выдают 750 FPS.
---
>> Вот Client-Side-Decorations, это действительно проблема.
> С ней живут и ничего, работает.Никто с таким идиотизмом не живёт, вы что? Нет мало-мальски распространённых графических систем с клиентскими декорациями.
Ну так история уже сто раз показала, что это в результате порождает гору других проблем. Те более, здесь же не заказчик с ежеминутно меняющимися требованиями, всё довольно инерционно и предсказуемо. Вон, на декорации в результате лепят натуральный костыль.
Жду результатов измерений в 2д и 3д релиза вяленого с последним релизом иксов. Не заставляй называть тебя балаболкой.
да-да, широкое на широкое, Андрей!
зы: про скрам когда-нить слышал?
А что там ещё осталось в иксах, что ещё не утащили в ведро и не сделали в Wayland? Список недостающего в студию, пожалуйста.
А черт его поймёт, что там есть, а чего нет - как раз потому что толкового описания полной архитектуры графического окружения с участием вейланда нет. Допустим, что они с мультитачем решили, с multipointer, какова вообще общая идея - свой ли диспетчер событий или ядро, один он или по диспетчеру на подсистему, есть ли какие-то предпочитаемые способы расширения, собираются ли переделывать/заменять libxkb, будет ли какой-то стандартный аналог XEmbed... вагон всего, в общем.Но суть даже не в этом - просто крайне интересно, есть ли кто-то, кто думаетв терминах архитектуры всего окружения, а не отдельных подсистем. Потому что если никого - то там зоопарк протоколов и технологий будет лет пять устаканиваться - и есть реальный шанс что получится несколько несовместимых стеков.
http://habrahabr.ru/post/148954/
> http://habrahabr.ru/post/148954/Да-да, там заодно хорошо рассказано и о недостатках иксов...
> А кому-нибудь попадалось описание полного стека, который они предлагают на замену иксам?
> Там вообще кто-то цельную конструкцию этого стека в голове держит?Какой стек, этот вяленый появился когда автор оптимизировал весь стек с драйверами иксами и тулкитами для смартфонов и прочей 320 на 300 дряни. В этом случае при рисовании меню из 4 строчек на этой постовой марке вайленд немного экономит ресурсов. ВСЕ. Ни о каких автокадах блендерах он и не мечтал. Теперь ждите еще 10 лет пока допишут недостающую часть (по сути перепишут Х заново).
Ну так сейчас вроде не он один этим занимается - я и надеялся (и надеюсь), что нашелся кто-то, кто думает о результате в целом. Потому что от этого зависит, есть ли смысл вообще смотреть на системы с вейландом.
> что нашелся кто-то, кто думает о результате в целом.Вы думаете, в команде Wayland найдётся талантливый архитектор? Самозародится? Почему же он тогда не появился 15 лет назад, когда портили Х?
> Потому что от этого зависит, есть ли смысл вообще смотреть
> на системы с вейландом.Могу сказать прямо сейчас - смысла нет.
Там сколько-то людей с иксорга есть вроде, работники интела, редхата... А пятнадцать лет - это, счиатй, смена поколений разрботчиков. Ладно, грустно всё это. Результат-то очевиден - победят бестолковые веб-приложения.
> Там сколько-то людей с иксорга есть вроде, работники интела, редхата...Ну так это именно те люди, что убили Х. :-) Ну вы посмотрите на XRender, на клиентский рендеринг шрифтов - этот идиотизм их рук дело.
> этот идиотизм их рук дело.Этот идиотизм позволяет всему этому хламу работать с более-менее приемлимой скоростью. Иксовый процесс и так довольно часто становится bottleneck-ом.
> Этот идиотизм позволяет всему этому хламу работать с более-менее приемлимой скоростью.XRender? Вы бы посмотрели, что он делает! Он заставляет любой примитив графики разбивать на трапеции. Именно он, скорее всего, всё и тормозит.
> XRender? Вы бы посмотрели, что он делает! Он заставляет любой примитив графики
> разбивать на трапеции. Именно он, скорее всего, всё и тормозит.Простите, тормозит даже тупой вывод битовых карт. Я как-то сильно сомневаюсь что файрфоксина играющая видео представляет оное в виде трапеций :)
> Простите, тормозит даже тупой вывод битовых карт. Я как-то сильно сомневаюсь что
> файрфоксина играющая видео представляет оное в виде трапеций :)Для видео, мне кажется, нужно делать что-то другое. А уж локальный вывод видео в FF - это за гранью добра и зла. Mplayer почему-то всё показывает очень быстро. А FF и Flash - тормозят.
Хотя, блин, даже делать особо ничего не надо было мозиллоидам - достаточно запускать Mplayer и встраивать его окно в браузер.
> Для видео, мне кажется, нужно делать что-то другое.А мне кажется что графическая система должна просто быстро выводить битмапы обсчитанные программой и не выпендриваться.
И вообще, имхо вносить ресурсоемкие операции в сервер чревато тем что какая-то апликуха не в меру ретиво абузанет ресурсы сервера и все остальное будет дико тупить. Когда тяжелые операции сбагрены на клиента, злоупотребление ими создает проблемы только клиенту, который начинает где-то там в своих кишках упираться. Ну и хрен с ним, можно пережить. А вот когда начинает клиниться вся графическая система вообще - вот это уже не айс.
Можно конечно порассуждать о планировке ресурсов, приоритетах и прочая. Но это будет грубым надругательством над KISS и просто кучей грабель, созданных на ровном месте.
> А уж локальный вывод видео в FF - это за гранью добра и зла. Mplayer
> почему-то всё показывает очень быстро. А FF и Flash - тормозят.Потому что специализированная апликуха "плеер" может позволить себе такую роскошь как знание о 100500 расширений конкретной подсистемы вывода графики, заморочиться с десятком драйверов и прочая. А для браузера это вообще не самый ключевой функционал. Зато все активнее применяются трансформации и эффекты, etc. По поводу чего авторы оных не сильно горят желанием лезть в такие дебри. Задача графической подсистемы в таком случае - не пыжиться помогать, а просто не мешаться под ногами.
> Хотя, блин, даже делать особо ничего не надо было мозиллоидам - достаточно
> запускать Mplayer и встраивать его окно в браузер.Да, кроме того что это сторонняя программа, которая может отсутствовать. И она создана для встраивания в браузер как топор создан для плавания по реке. То-есть, HTML5 подразумевает HTMLные контролы для управления + их доступность из JS и что там еще, что малость неудобно реализовать в таковых условиях.
>> Для видео, мне кажется, нужно делать что-то другое.
> А мне кажется что графическая система должна просто быстро выводить битмапы обсчитанные
> программой и не выпендриваться.Программа не думает в терминах битмапов. Она, надо сказать, даже в терминах линий не думает. Поэтому где-то должны быть рисовалки. Ну уж лучше иметь одну рисовалку на всех, чем 10 тысяч костылей.
Самый маленький поток данных, как вы понимаете, на уровне приложений, а чем ближе к монитору - тем поток больше и больше. Поэтому если сделать рисовалку-растеризатор в X-сервере, то практически любой сети хватит для почти любой прикладной программы.
> И вообще, имхо вносить ресурсоемкие операции в сервер чревато тем что какая-то
> апликуха не в меру ретиво абузанет ресурсы сервера и все остальное
> будет дико тупить.Для этого есть механизмы типа ulimit в ОС, многопоточность и т.д.
> Ну и хрен с ним, можно пережить. А вот когда
> начинает клиниться вся графическая система вообще - вот это уже не
> айс.Обычно и клиент, и сервер на одной машине. Поэтому падает всё вместе в обоих случаях.
> Можно конечно порассуждать о планировке ресурсов, приоритетах и прочая. Но это будет
> грубым надругательством над KISS и просто кучей грабель, созданных на ровном
> месте.Можно дать флаг в руки ОС - у неё есть эффективные механизмы разделения памяти.
> Потому что специализированная апликуха "плеер" может позволить себе такую роскошь как знание
> о 100500 расширений конкретной подсистемы вывода графики, заморочиться с десятком драйверов
> и прочая. А для браузера это вообще не самый ключевой функционал.Так а нахрена он вообще туда полез, где есть чудесные спец. аппликухи?
> Да, кроме того что это сторонняя программа, которая может отсутствовать. И она
> создана для встраивания в браузер как топор создан для плавания по
> реке.Для встраивания в браузер есть Х. Которые как раз для этого встраивания и делались. А MPlayer можно с собой таскать (на убогих ОС без пакетов) либо указать в зависимостях (на продвинутых ОС).
> То-есть, HTML5 подразумевает HTMLные контролы для управления + их доступность
> из JS и что там еще, что малость неудобно реализовать в
> таковых условиях.Ну у MPlayer вообще-то есть всякие сторонние интерфейсы для делания гуюшек. :-) А не нравится MPlayer, есть VLC и xinelib (это вообще библиотека - линкуй-не хочу).
>> программой и не выпендриваться.
> Программа не думает в терминах битмапов.Это почему же, какая-нибудь рендерилка PDF, смотрелка жыпегов, браузер или прочая очень даже может думать в терминах битмапов.
> Она, надо сказать, даже в терминах линий не думает.
Это как бы сильно зависит от программы и ее природы.
> Поэтому где-то должны быть рисовалки. Ну уж лучше
> иметь одну рисовалку на всех, чем 10 тысяч костылей.Чтобы потом обнаружить что есть дофига программ которым ее не хватило так что на системную как обычно забили. Заодно появится пространство для создания проблем системе и ее стабильности и юзабельности - неуемный юзеж ресурсов сервера программой.
> Самый маленький поток данных, как вы понимаете, на уровне приложений, а чем
> ближе к монитору - тем поток больше и больше.Но я понимаю и то что сжатая дельта между кадрами десктопа при ничегонеделании или обычном юзании оного - весьма невелика. Кроме того это просто и брутально и при том работает. Собственно, сжатые видеоформаты пытаются в чем-то похожий подход применять еще более продвинуто и для произвольных сцен вообще.
> Поэтому если сделать рисовалку-растеризатор в X-сервере, то практически любой
> сети хватит для почти любой прикладной программы.Зато элементарный необдуманный cat в терминалке станет вызывать не клинч самой терминалки а клинч всей графики, т.к. теперь по рендерингу мегазов в вектор надрывается не терминалка а графическая подсистема. И если терминалке щедулер процессов не даст борзеть и вообще ее клин на минуту пережить еще можно, то вот мне как-то не хочется понаблюдать то же самое но в исполнении графического сервера. ИМХО он должен быть неубиваем злодеяниями апликух, прост и легок.
> Для этого есть механизмы типа ulimit в ОС,
Пардон, а что лимитировать то? Жрач ресурсов графическим сервером? Сэр, при этом начнет тупить и остальная графика в системе. Юзабилити превратится в д@рьмо.
> многопоточность и т.д.
Решает проблему лишь частично. Есть 1-ядерные системы. И кроме того я могу себе представить кайф когда проц взревет всеми турбинами потому что теперь cat в терминалке рендерится на куче ядер и это вообще типа приоритетная операция (низкоприоритетны графический сервер я как-то плохо себе представляю в отличие от терминалки которой можно nice в случае чего твикнуть накрайняк).
>> начинает клиниться вся графическая система вообще - вот это уже не айс.
> Обычно и клиент, и сервер на одной машине. Поэтому падает всё вместе в обоих случаях.Не, пардон, в случае вещей типа интенсивного рендеринга текста оптом - клинит только программу рендерер. К счастью. Как раз потому что не в сервере. Иксы и так не в меру часто дофига ресурсов жрут чтобы туда еще и такое сбагривать, thank you very much.
> Можно дать флаг в руки ОС - у неё есть эффективные механизмы разделения памяти.
Это вообще не о дележе памяти а о том что программа сможет запросить дофига супертяжелых операций в сервере. Если она сама их делает - это ее проблемы, cpu scheduler как-нибудь разгребется и время остальным выкроит. Если она это делает в графическом сервере - это проблемы всей системы и юзера уже. Выкроить время за счет сервера конечно можно, но при этом вообще вся графика будет в том еще пролете и пользоваться такой системой будет на редкость мерзостно. А кому нравится система где клинит мышь, перестают таскаться окна и прочая или все это тормозит?
> Так а нахрена он вообще туда полез, где есть чудесные спец. аппликухи?
Потому что мир меняется. Чудесные спец. апликухи не умеют хтмл парсить. А пожелание выложить ролик с своего дня рождения на хоумпаге или где там еще, чтоб его можно не отходя от кассы посмотреть было - простое и нормальное человеческое желание, имхо. Я нахожу его вполне резонным. И оно наверняка надо намного большему числу гуманоидов чем та же математика с ремотной машины. А почему, собственно, хотелки этих гуманоидов должны остаться в пролете, а ваши - нет? И вы уверены что разработчики браузеров, графических стеков и прочего ответят на этот вопрос так же как и вы?
> Для встраивания в браузер есть Х. Которые как раз для этого встраивания и делались.
Так д@рьмово работает же по дефолту и без окостыливания. Что собственно всех и достало. Браузер - более-менее обычная кроссплатформенная апликуха. Заставлять его знать о 100500 графических подсистемах и их интимных особенностях - ад и изврат.
> А MPlayer можно с собой таскать (на убогих ОС
> без пакетов) либо указать в зависимостях (на продвинутых ОС).Я повторяю, он для этого создан как топор для плавания по рекам. Мало кто хочет таскать здоровый кус кода весящий почти как браузер, с 100500 патентованных форматов (как раз копирасы из MPEG LA с удовольствием засудят), умением играть всякие там двд и чего там еще крайне необходимого в БРАУЗЕРЕ. Этак nero требовавший свежий директикс покажется не такой уж и переросточной штукой. Хотя требование DX для нарезки болванок звучит не менее дико чем браузер умеющий зачем-то играть двдюки :)
> Ну у MPlayer вообще-то есть всякие сторонние интерфейсы для делания гуюшек. :-)
> А не нравится MPlayer, есть VLC и xinelib (это вообще библиотека - линкуй-не хочу).Проблема в том что там нафиг не упали суперуниверсальные мегакомбайны, умеющие готовить кофе, играть дивидюки и весящие в результате как весь браузер.
Кроме того есть еще canvas, например. И просто трансформации JSом и CSSом. А как насчет этого? Это тоже в mplayer будем пихать? Каким манером? :)
> Это почему же, какая-нибудь рендерилка PDF, смотрелка жыпегов, браузер или прочая очень
> даже может думать в терминах битмапов.Это всё-таки исключения. Да и те, честно говоря, думают битмапами только в очень специальных местах - собственно, в одном окне.
> Чтобы потом обнаружить что есть дофига программ которым ее не хватило так
> что на системную как обычно забили.Ну сейчас эти программы пользуются рисовалками Qt и Gtk. Значит, их всё-таки хватает? Предлагается с высот текущего опыта понять, что нужно программам. И дорабатывать единую системную рисовалку по потребностям.
> Но я понимаю и то что сжатая дельта между кадрами десктопа при
> ничегонеделании или обычном юзании оного - весьма невелика.Зато шрифты, dpi и настройки совершенно не те, что на терминале.
>> Поэтому если сделать рисовалку-растеризатор в X-сервере, то практически любой
>> сети хватит для почти любой прикладной программы.
> Зато элементарный необдуманный cat в терминалке станет вызывать не клинч самой терминалки
> а клинч всей графикиНет, если вы рендеринг графики в битмап будете делать для каждой программы в своём процессе.
> Пардон, а что лимитировать то? Жрач ресурсов графическим сервером? Сэр, при этом
> начнет тупить и остальная графика в системе. Юзабилити превратится в д@рьмо.Делим граф. сервер на "голову" - композитор, которая кидает результаты рендера на видяху, и сами рисовалки - форки одного процесса, по одному на аппликуху. Рисовалки лимитированы по ulimit, голова получает битмап по shared memory, все довольны.
Связь с аппликухами у рисовалок малонагруженная => можно и по сети.
> Решает проблему лишь частично. Есть 1-ядерные системы.
Ну у нас же не Винды, чтоб "сейчас, покажу многозадачность, только дискетку отформатирую".
> cat в терминалке рендерится на куче ядер
А сейчас он что - не рендерится? Он точно также занимает столько ядер, сколько позволяет рисовалка тулкита.
> приоритетная операция (низкоприоритетны графический сервер я как-то плохо себе представляю
> в отличие от терминалки которой можно nice в случае чего твикнуть
> накрайняк).Если разделить Х сервер на рисовалки и композитор, то всё сможете.
> Не, пардон, в случае вещей типа интенсивного рендеринга текста оптом - клинит
> только программу рендерер.По памяти ложится всё.
> Это вообще не о дележе памяти а о том что программа сможет
> запросить дофига супертяжелых операций в сервере.Выделим ей свою рисовалку в битмап на сервере - свой процесс.
>> Так а нахрена он вообще туда полез, где есть чудесные спец. аппликухи?
> Потому что мир меняется. Чудесные спец. апликухи не умеют хтмл парсить.Им не надо парсить хтмл. Парсить должен браузер. А где нашёл тег video, вызывать MPlayer, встраивать Mplayer в своё окно и радоваться жизни. Или вызвать библиотеку xine, встраивать в своё окно и см. выше. Или VLC.
А вместо этого, мозиллоиды делают свой велосипед.
> Так д@рьмово работает же по дефолту и без окостыливания. Что собственно всех
> и достало. Браузер - более-менее обычная кроссплатформенная апликуха. Заставлять его знать
> о 100500 графических подсистемах и их интимных особенностях - ад и
> изврат.О 3-х! Ну у них, у 3-х разные системы встраивания окон. Боже, какая трагедия. Вместо того, чтобы прочесть 3 мануала, мы напишем своё говно, которое будет тормозить.
> Мало кто хочет таскать здоровый кус кода весящий почти как браузер,
В нормальных системах его не надо таскать, он уже есть.
> Проблема в том что там нафиг не упали суперуниверсальные мегакомбайны, умеющие готовить
> кофе, играть дивидюки и весящие в результате как весь браузер.Опа. А браузер, который умеет видео показывать - это принцип KISS? ;-)
Да ну, FF/Chrome/Opera/IE - это разжиревшие монстры, делающие всё, но крайне фигово.
>> даже может думать в терминах битмапов.
> Это всё-таки исключения.Не согласен. Реалии современного мира таковы что большинство программ будут рады до поросячьего визга тупому но быстрому фреймбуферу + opengl. За отсутствием первого в нормальном виде и тормознутости иксов таковым все чаще выступает второе, хоть это и довольно странный метод быстрого делания 2D операций.
> Да и те, честно говоря, думают битмапами только в
> очень специальных местах - собственно, в одном окне.Зато именно там меня и волнует перфоманс больше всего. Вот на тормоза оконного интерфейса я не жалуюсь. А вот на то что FPS в canvas оставляет желать, проигрывание видео в браузере в иксах проводит не меньше чем требуется на декодирование замороченного современного формата сжатия видео - мне как-то совсем не нравится. Ну и так далее. По итогам я все-таки за то чтобы у меня была была простая и быстрая граф. подсистема которую хрен какая сволочь заклинит. Даже если прога неидеально написана и что там еще. Пусть лучше прогу клинит чем все вокруг, system wide. Так и виновника локализовать проще и бороться с ним намного сподручнее и глюков в базовой подсистеме будет минимум. Тем более что простой код отладить легче. И если глюки в программе ведут к отказу только 1 программы, то проблемы графического сервера могут иметь system-wide эффекты. По поводу чего бодал я там лишний код. Хотя может быть кто-то и лю, когда "ой, иксы упали - как серпом по йайцам", но этот кто-то - не я. Одно дело если из-за бага в гномовском рендерере трапнется 1 программа и другое - если трапнется весь сервер графики.
> Ну сейчас эти программы пользуются рисовалками Qt и Gtk. Значит, их всё-таки хватает?
А если посмотреть на браузеры колхозящие канвасы и видеоплееры, трансформации и что там еще + забить на эстетство и концепции, получится что наиболее просто, логично и так далее - дубовый но быстрый фреймбуфер. Ну, с чутком продвинутостей. Парни пилящие вэйланд кажется это осознали и решили не ссать против ветра а использовать ветер в свое благо.
> Предлагается с высот текущего опыта понять, что нужно программам. И
> дорабатывать единую системную рисовалку по потребностям.У меня есть большие сомнения что это приведет к хорошему результату на пратике. Я уже вроде бы озвучил соображения стабильности, абузивного использования ресурсов. Чем нечто проще и быстрее - тем там меньше багов и софту в общем случае сложнее это положить какими либо действиями. А system-wide отказ графики - это немного не то что нравится людям, если вы вдруг еще не заметили. По поводу чего у меня стремление напихать в и без того страдающий граблями сервер еще тонну хлама как-то не вызывают оптимизма. Иксы куда засунуто половина кути и гтк? No way! Оно подохнет от своего же веса, заканав юзерей полным вылетом граф. системы и/или жесткими тормозами по поводу и без.
> Зато шрифты, dpi и настройки совершенно не те, что на терминале.
Абсолютно. С другой стороны это позволяет четко понимать без чего ты останешься при отвале сети. А в мире мобильных пользователей и беспроводных сетей все это еще и не пустой звук. Эфир штука довольно эфемерная. Так что такой вопрос меня в ряде случаев может интересовать.
>> а клинч всей графики
> Нет, если вы рендеринг графики в битмап будете делать для каждой программы в своём процессе.Так он уже и делается в своем процессе как раз, но вам это не нравится :). Довешивать к процессу по процессу-спутнику? Не-не-не, вот уж точно нафиг.
>> начнет тупить и остальная графика в системе. Юзабилити превратится в д@рьмо.
> Делим граф. сервер на "голову" - композитор, которая кидает результаты рендера на
> видяху, и сами рисовалки - форки одного процесса, по одному на аппликуху.Не, спасибо, я KISS люблю. А это звучит как источник головняка от добавочного усложнения + отличный кандидат на resource hogging.
> Рисовалки лимитированы по ulimit, голова получает битмап по shared memory, все довольны.
> Связь с аппликухами у рисовалок малонагруженная => можно и по сети.Вот что-то такое и называют словом overengineering. Могу себе представить как все это будет работать, каково все это программить и какова будет надежность всего этого.
>> Решает проблему лишь частично. Есть 1-ядерные системы.
> Ну у нас же не Винды, чтоб "сейчас, покажу многозадачность, только дискетку отформатирую".Да, однако вы предлагаете выносить тяжелые и длительные операции в сервер графики. Одно дело если программа как бы ни изгалялась но сделает плохо только себе и другое - если она сделает плохо вместо этого серверу графики и/или прогрузит какие-то межпроцессные интерфейсы лишний раз.
> А сейчас он что - не рендерится? Он точно также занимает столько ядер, сколько
> позволяет рисовалка тулкита.Т.е. как правило 1 как максимум. С нормальным шедулингом проца на остальных, т.к. вот что-что а дележ времени CPU в честных многозадачках делают на совесть. В крайнем случае можно просто понизить приоритет процессу. Тулкит будучи в адресспейсе этого процесса будет вынужден довольствоваться тем же шедулингом что и остальной процесс. Дешево и сердито.
> Если разделить Х сервер на рисовалки и композитор, то всё сможете.
Мне не нравится идея что при запуске мизерной прожки в пару к ней будет взлетать огроменный процесс с рендерерами на все случаи жизни каждый раз. Я таким пользоваться не буду. Я конечно могу вообразить себе пул процессов/тредов по числу ядер CPU например, но это залет на сложную полисовку ресурсов рендерера и совершенно неочевидное так сходу вычисление тяжести графических операций. В общем как-то переусложненно и страшно.
>> Не, пардон, в случае вещей типа интенсивного рендеринга текста оптом - клинит
>> только программу рендерер.
> По памяти ложится всё.Не заметил. Вот случаев когда иксы уперлись в проц и в них уперлись программы - я видел, да.
>> запросить дофига супертяжелых операций в сервере.
> Выделим ей свою рисовалку в битмап на сервере - свой процесс.Ну, выделяйте. А я не жалую такие переростки и как-нибудь пешком постою.
>> Потому что мир меняется. Чудесные спец. апликухи не умеют хтмл парсить.
> Им не надо парсить хтмл. Парсить должен браузер. А где нашёл тег
> video, вызывать MPlayer, встраивать Mplayer в своё окно и радоваться жизни.
> А вместо этого, мозиллоиды делают свой велосипед.Потому что это кривое и грабельное решение, требующее внешнего компонента, страдающего патентными проблемами и обладающего дофига лишнего функционала. Который весит как весь браузер, пардон. У мозилловцев хватает ума понять сколько головняка принесет им и их юзерам данный выбор. И не только у мозилловцев.
Кроме того данный подход не прокатит с анимациями, трансформациями и просто canvas. Ну или почему они должны работать медленно?
>> о 100500 графических подсистемах и их интимных особенностях - ад и изврат.
> О 3-х! Ну у них, у 3-х разные системы встраивания окон. Боже, какая трагедия.Приличная. В идеальном мире апликушники вообще не должны ничего знать о всем этом крапе. Поскольку они сами себе не враги - они к этому стремятся. И правильно делают.
> Вместо того, чтобы прочесть 3 мануала, мы напишем своё гoвно, которое будет тормозить.
Три мануала и 100500 дополнений х 3 к каждому, etc, etc.
>> Мало кто хочет таскать здоровый кус кода весящий почти как браузер,
> В нормальных системах его не надо таскать, он уже есть.В нормальных системах его по дефолту нет. Ибо в сша есть патенты и потому в большинство систем его по дефолту класть просто боятся - оно умеет дофига патентованных форматов. Уже хорошая заявка на проблемы в США. А оно кому-то надо?
>> кофе, играть дивидюки и весящие в результате как весь браузер.
> Опа. А браузер, который умеет видео показывать - это принцип KISS? ;-)Как сказать? Если сравнивать с тем что набито на все случаи жизни в мплеере, сие вполне потянет на KISS, пожалуй. Относительно мплеера. Металлический ножик в понимании дикаря - довольно сложная штука, которую явно не сделаешь голыми руками. Но на фоне лазерного резака с программным управлением это все-таки довольно простой предмет :)
> Да ну, FF/Chrome/Opera/IE - это разжиревшие монстры, делающие всё, но крайне фигово.
Ну не все. А лишь то чего хотели пользователи. Спрос рождает предложение.
> Реалии современного мира таковы что большинство программ будут рады до поросячьего визга тупому но быстрому фреймбуферу + opengl. За отсутствием первого в нормальном виде и тормознутости иксов таковым все чаще выступает второе, хоть это и довольно странный метод быстрого делания 2D операций.первое было в виде дирктфб уже неизвестно когда, второе в вяленому наблюдается в усечённом виде - блобы то не спешат переносить. упс.
> Не согласен. Реалии современного мира таковы что большинство программ будут рады до
> поросячьего визга тупому но быстрому фреймбуферу + opengl.Большинство программ чертят формочки. На кой ляд им OpenGL?
> Зато именно там меня и волнует перфоманс больше всего. Вот на тормоза
> оконного интерфейса я не жалуюсь. А вот на то что FPS
> в canvas оставляет желать, проигрывание видео в браузере в иксахЭто исключительно потому, что браузер сделан через попу. Сделаете вы другую система, а браузер всё одно будет сделан через попу.
> По итогам я все-таки за то чтобы у меня была была простая
> и быстрая граф. подсистема которую хрен какая сволочь заклинит.Эта задача вполне решаема и с общесистемной рисовалкой. См. те же Винды.
> А если посмотреть на браузеры колхозящие канвасы и видеоплееры, трансформации и что
> там еще + забить на эстетство и концепции, получится что наиболее
> просто, логично и так далее - дубовый но быстрый фреймбуфер. Ну,
> с чутком продвинутостей.Это для 3-х уродцев браузеров. А для огромного кол-ва GUIшных программ ничего, кроме удобного интерфейса рисования формочек не нужно.
> Парни пилящие вэйланд кажется это осознали и решили
> не ссать против ветра а использовать ветер в свое благо.Мне кажется, вы им сильно льстите. W всё-таки пишут не приходя в сознание.
> Иксы куда засунуто половина кути и
> гтк? No way! Оно подохнет от своего же веса, заканав юзерей
> полным вылетом граф. системы и/или жесткими тормозами по поводу и без.Там и так есть рисовалка. Предлагается её просто обновить. Не более. Откуда обновлять - да вот из Cairo.
> Абсолютно. С другой стороны это позволяет четко понимать без чего ты останешься
> при отвале сети. А в мире мобильных пользователей и беспроводных сетей
> все это еще и не пустой звук. Эфир штука довольно эфемерная.
> Так что такой вопрос меня в ряде случаев может интересовать.И как вы собираетесь программу с мобильного телефона с экраном 300 на 300 транслировать в 24-х дюймовый дисплей с помощью битмапов? Вы же умрёте рассматривая крякозябры. А с отрисовкой на сервере всё будет очень прилично.
>> Ну у нас же не Винды, чтоб "сейчас, покажу многозадачность, только дискетку отформатирую".
> Да, однако вы предлагаете выносить тяжелые и длительные операции в сервер графики.Они и так вынесены во многих системах. В тех же Виндах, к примеру. И ничего, не умирают машины.
> Одно дело если программа как бы ни изгалялась но сделает плохо
> только себе и другое - если она сделает плохо вместо этого
> серверу графики и/или прогрузит какие-то межпроцессные интерфейсы лишний раз.Ну вот как раз нарисовалась чудесная архитектура:
Композитор (пусть даже и W) < X с рисовалкой <= команды от тулкита <- команды от аппликухи
Плюс добавить для битмапов проброс в композитор сразу. Связь <= можно сделать сетевой. :-) Либо, можно сделать связь <- сетевой. Но это уж слишком радикально.
> Т.е. как правило 1 как максимум. С нормальным шедулингом проца на остальных,
> т.к. вот что-что а дележ времени CPU в честных многозадачках делают
> на совесть.Ну так и тут поделится нормально, раз ОС нормальная.
> В крайнем случае можно просто понизить приоритет процессу. Тулкит
> будучи в адресспейсе этого процесса будет вынужден довольствоваться тем же шедулингом
> что и остальной процесс. Дешево и сердито.Да никто не сбрасывает этот приоритет. Хотя, вы также сможете и снизить приоритет рисовалки.
> Мне не нравится идея что при запуске мизерной прожки в пару к
> ней будет взлетать огроменный процесс с рендерерами на все случаи жизни
> каждый раз.Он уже взлетел при запуске оконного менеджера или первой Xовой программы. Он должен будет лишь форкнуться. То есть, у него должно быть максимум разделяемых данных и минимум своих. Ну есть же всякие CoW и т.д.
> Не заметил. Вот случаев когда иксы уперлись в проц и в них
> уперлись программы - я видел, да.Я - нет.
> Кроме того данный подход не прокатит с анимациями, трансформациями и просто canvas.
> Ну или почему они должны работать медленно?Ну криво сделан браузер. Почему криво - см. видео, которое реализовано в духе NIH. Я категорически с вами несогласен, что MPlayer/xine/VLC все сделаны неудовлетворительно. Хоть что-то из них можно было взять. И вырезать те форматы, что не подходят (методами configure).
>> Вместо того, чтобы прочесть 3 мануала, мы напишем своё гoвно, которое будет тормозить.
> Три мануала и 100500 дополнений х 3 к каждому, etc, etc.??? Ну если вы хотите писать программу под граф. систему, желательно что-то знать о граф. системе.
> В нормальных системах его по дефолту нет. Ибо в сша есть патенты
> и потому в большинство систем его по дефолту класть просто боятся
> - оно умеет дофига патентованных форматов. Уже хорошая заявка на проблемы
> в США. А оно кому-то надо?Хорошо, отконфигурьте так, чтобы был лишь ваш формат, и всуньте в инсталлятор. Как-то sqlite всовываете, так почему libxine нельзя?
> Как сказать? Если сравнивать с тем что набито на все случаи жизни
> в мплеере, сие вполне потянет на KISS, пожалуй.Там есть configure. Я же его компилял под Solaris/SPARC.
>> поросячьего визга тупому но быстрому фреймбуферу + opengl.
> Большинство программ чертят формочки. На кой ляд им OpenGL?А это тем кому формочек не хватило и/или захотелось эффектов.
> Это исключительно потому, что браузер сделан через попу. Сделаете вы другую система,
> а браузер всё одно будет сделан через попу.Root cause именно тормозные 2D операции в иксах. Остальное следствие. Ведь на других графических системах браузеры таким не страдают.
> Эта задача вполне решаема и с общесистемной рисовалкой. См. те же Винды.
Наверное именно поэтому MS в офисе юзает кастом контролы, придумали всякие winforms и прочие WTF^W WPF-ы. А еще рисовалка может в GDI программах применять тему или не применять. По факту такой бардак получается что линух где установлена синхронная тема GTK и Qt (или просто рендеринг qt через gtk) на фоне этого просто эталон одинакового вида программ получится запросто ;)
> Это для 3-х уродцев браузеров. А для огромного кол-ва GUIшных программ ничего,
> кроме удобного интерфейса рисования формочек не нужно.А еще некоторым программам надо поболее. Компьютеры нынче используются для визуализации разных процессов, в том числе и достаточно быстрых, работы с графикой, видео, эффектами и чем там еще. Есть еще и игры наконец. Как бы программы с формочками - это прекрасно но их сетевая прозрачность в том виде как это делают иксы - нужна полутора землекопам. А как насчет осциллограмму снятую микроконтроллером на usb с приличным FPS показать? Ну так, первое что в бошку взбрело.
>> Парни пилящие вэйланд кажется это осознали и решили
>> не ссать против ветра а использовать ветер в свое благо.
> Мне кажется, вы им сильно льстите. W всё-таки пишут не приходя в сознание.Ну это мы будем посмотреть. По-моему они отлично понимают то что делают. Да, вам и arisu это наверное не понравится.
> Там и так есть рисовалка. Предлагается её просто обновить. Не более. Откуда
> обновлять - да вот из Cairo.Угу, представляю себе если такие навороты как в cairo в иксы засунуть. Как по мне так трублешутить тормоза 1 программы проще чем system-wide компонента и проблем меньше.
> И как вы собираетесь программу с мобильного телефона с экраном 300 на
> 300 транслировать в 24-х дюймовый дисплей с помощью битмапов?Это у вас он 300х300 пикселов, а у меня 800х480. По поводу чего сие вполне прилично выглядит на мониторах, что растянутое что в окне.
> Вы же умрёте рассматривая крякозябры. А с отрисовкой на сервере всё будет очень прилично.
Да вот живой как-то пока и не особо понимаю потуг осчастливить меня черти-чем.
>> Да, однако вы предлагаете выносить тяжелые и длительные операции в сервер графики.
> Они и так вынесены во многих системах. В тех же Виндах, к примеру. И ничего, не умирают машины.Как бы вам сказать то? Положить GDI и оставить систему без руля и без ветрил - национальный вид спорта тех кто знает что такое GDI :). Потом даже таскманагер прорисоваться не сможет, ну и все - готов котенок. Даже снять проблемную задачу нельзя. Наиболее очевидные грабли такого плана MS хоть немного подлатал где-то в районе висты или семерки, чтоли. Зато стало клинить мышь и вообще графику при нагрузке на систему. Ноги вытащили - хвост увяз. Я что-то не хочу себе систему с такими же свойствами.
> Ну вот как раз нарисовалась чудесная архитектура:
> Композитор (пусть даже и W) < X с рисовалкой <= команды от
> тулкита <- команды от аппликухиВсе бы ничего но прослоек многовато.
> Плюс добавить для битмапов проброс в композитор сразу. Связь <= можно сделать
> сетевой. :-) Либо, можно сделать связь <- сетевой. Но это уж слишком радикально.Вообще, я могу наблюдать тенденцию что вэйлэнд будет дружить с иксами. Как минимум некое время - точно. Потому что небольшая но все-таки часть программ юзает именно иксовый протокол а не тулкиты и сразу всех жестко прокатывать на работу такого софта как-то не есть правильно.
>> т.к. вот что-что а дележ времени CPU в честных многозадачках делают на совесть.
> Ну так и тут поделится нормально, раз ОС нормальная.Да, однако это не значит что времена выполнения запросов программ поделятся нормально. По крайней мере если не городить ужас с персональым процессом-спутником или крутой арбитр ресурсов.
> Да никто не сбрасывает этот приоритет. Хотя, вы также сможете и снизить
> приоритет рисовалки.Это вариант только в случае изврата когда эта рисовалка обслуживает только 1 процесс (что больно жирно, пардон). Иначе это затронет иные процессы.
> Он уже взлетел при запуске оконного менеджера или первой Xовой программы. Он
> должен будет лишь форкнуться. То есть, у него должно быть максимум
> разделяемых данных и минимум своих. Ну есть же всякие CoW и т.д.Оно конечно да, но посмотрев на апач vs nginx я как-то за последнего. А опач но из графической подсистемы мне почему-то тоже не хочется. Fork в юниксах конечно достаточно прикольный и эффективный вызов vs создание процесса с нуля, но это не значит что его надо везде тыкать по максимуму. "Когда у вас в руках молоток, все вокруг кажется гвоздями"? :)
>> уперлись программы - я видел, да.
> Я - нет.На программах с формочками так не получится. Для этого надо программы с выводом графики все-таки. Судя по тому что вы активно кивали на тормоза оконных менеджеров, вы с такими программами просто дел не имеете вообще.
> духе NIH. Я категорически с вами несогласен, что MPlayer/xine/VLC все сделаны неудовлетворительно.
Они сделаны нормально. Просто неудобно как-то промышленным лазерным резаком шкуру с апельсина снимать. Оптимальнее взять примитивный ножик.
И да, опять же - вы упорно игнорируете неудобный вам топик - вычисляемая графика в canvas которую никакой плеер в принципе не осилит (если оно умеет вычисления - это что угодно но только не плеер уже) и прочие эффекты, являющиеся частью стандарта. А интересно, SVG рендерер тоже надо целиком в иксы втолкать? Вместе с его анимациями и прочая? А анимированные картинки - их тоже плееру? В общем ИМХО граф. система должна быть быстрой. Это снимает 100500 проблем 1 махом.
>> Три мануала и 100500 дополнений х 3 к каждому, etc, etc.
> ??? Ну если вы хотите писать программу под граф. систему, желательно что-то
> знать о граф. системе.Если вы не заметили - обычно прикладники пишущие открытый софт как правило хотят юзать кроссплатформенный тулкит и не забивать себе бошку особенностями конкретных графических подсистем. Прибиваться гвоздями к 1 граф. системе - дурной тон. А самому все особенности каждой изучать во всех ОС коих дофига - упухнуть можно. Вот вы готовы изучить графические стеки всех ОС поддерживаемых GTK и Qt? За что-то такое их и юзают. И за это им и делегируют рендеринг кучи виджетов и прочая.
> Хорошо, отконфигурьте так, чтобы был лишь ваш формат, и всуньте в инсталлятор.
> Как-то sqlite всовываете, так почему libxine нельзя?Скулайт изначально заточен на встраивание и добавляет лишь 300 кило кода со всми наворотами. И да, когда я в последний раз видел плееры на основе xine они зарекомендовали себя жутко глючными. И да, а что насчет canvas и прочих эффектов? А вот расскажите - есть допустим тест peacekeeper. В частности часть оного на скорость меняет элементы HTML, устраивая довольно красивый обсчитываемый эффект в стиле плазмоидов. Не понятно почему это должно давать паршивый FPS. И да, хочу посмотреть как вы ЭТО отдадите в libxine или какому там еще плееру. Если вы не поняли, в браузерах все идет к тому что это будет некая гибридная мультимедийно-документально-программная среда. Логичная точка конвергенции технологий.
> Там есть configure. Я же его компилял под Solaris/SPARC.
Там конечно есть, НО в нем настолько много всего лишнего что попытка впереть его в браузер будет напоминать советский анекдот про опиловку танка напильником до получения формы трактора.
> А это тем кому формочек не хватило и/или захотелось эффектов.Такие, как показывает практика, идут стоем на ЙУХ. Всё равно, сделать компоненты красивее, чем у E17/16 не получится. А выглядеть будет не в пример топорнее и неудобнее.
> Root cause именно тормозные 2D операции в иксах. Остальное следствие. Ведь на
> других графических системах браузеры таким не страдают.Крайне сомнительно. Почему браузеры и флеш так безбожно тормозят с видео? Скорее просто их бэкенды под Х сделаны через попу.
> Наверное именно поэтому MS в офисе юзает кастом контролы, придумали всякие winforms
> и прочие WTF^W WPF-ы.Ну нельзя же в одной бобочке 20 лет ходить. Ясен пень, что нужно рисовалку развивать. Но говорить, что не надо носить фуфайку из-за того, что она пачкается и портится!
Кроме того, вы не учитываете, что введение новых компонент сперва в офис, а потом в Винды - это давняя традиция MS. Я бы даже сказал, монополистическое жлобство.
> А еще некоторым программам надо поболее. Компьютеры нынче используются для визуализации
> разных процессов, в том числе и достаточно быстрых, работы с графикой,
> видео, эффектами и чем там еще.Больше 60 ФПС человеку не нужно.
> Есть еще и игры наконец.
> Как бы программы с формочками - это прекрасно но их сетевая
> прозрачность в том виде как это делают иксы - нужна полутора
> землекопам.Не сказал бы. Сейчас много клиент-серверных программ внутри предприятий, на локальной сети. Часто делают на браузерах, хотя проще сделать через Х. Всё-таки, С++ значительно приятнее JavaScript'a. Да и быстрее.
> А как насчет осциллограмму снятую микроконтроллером на usb с приличным
> FPS показать? Ну так, первое что в бошку взбрело.На 100 мегабитной сети легко. Я же работаю по такой сети с Математикой. Именно работаю, а не мучаюсь. При этом легко работает Animate, перестраивает графики как на локальной машине. И это даже на извращении Xming, не только на Xorg'е.
В локалке сетевая прозрачность Х со всем, кроме видео, работает. Просто многие хотят и через Интернет. А когда оно, увы, обламывается, говорят "так не доставайся же ты никому!". И ратуют за выпиливание сетевой прозрачности.
> Ну это мы будем посмотреть. По-моему они отлично понимают то что делают.
Тогда бы они не орали, что хотят десктоп, а там client-side-decorations. Вот это - чистой воды маразм!
> Угу, представляю себе если такие навороты как в cairo в иксы засунуть.
> Как по мне так трублешутить тормоза 1 программы проще чем system-wide
> компонента и проблем меньше.Да ничего не будет. Сейчас же cairo не тормозит. А так она даже не будет делать трапеизацию всего и всея.
> Это у вас он 300х300 пикселов, а у меня 800х480.
Ну нельзя же так смешить, право слово! Я на меньше, чем на 1920хЧто-то стараюсь не работать. А как появятся retina по гуманной цене, сразу же перейду на них.
> Зато стало клинить мышь и вообще графику при
> нагрузке на систему. Ноги вытащили - хвост увяз. Я что-то не
> хочу себе систему с такими же свойствами.Ну тут ядро Linux с его планировщиком и nice подкачало. Увы, не Haiku. :-( Нужно выставлять приоритет прорисовщику чуть выше, чем обычному процессу, и всё будет ок.
Впрочем, планировщик Windows - это вообще патентованное говно - он начинает лагать, когда процессов становится больше, чем ядер. Поэтому может быть на Linux всё и обойдётся и так.
>> Ну вот как раз нарисовалась чудесная архитектура:
>> Композитор (пусть даже и W) < X с рисовалкой <= команды от
>> тулкита <- команды от аппликухи
> Все бы ничего но прослоек многовато.Их и сейчас столько же, просто рисовалка внутри тулкита. А у меня даже более UNIXвейно. :-)
> Вообще, я могу наблюдать тенденцию что вэйлэнд будет дружить с иксами.
Иначе он вообще будет слит в унитаз. Он же не поддерживает без них ни одного коммерческого приложения под Linux. Не поддерживает ни одной графопостроительной программы.
>>> т.к. вот что-что а дележ времени CPU в честных многозадачках делают на совесть.
>> Ну так и тут поделится нормально, раз ОС нормальная.
> Да, однако это не значит что времена выполнения запросов программ поделятся нормально.
> По крайней мере если не городить ужас с персональым процессом-спутником или
> крутой арбитр ресурсов.Почему? Зачем арбит? Рисовалка отдаёт битмап композеру - это быстро, а когда рисует - долгий процесс, её сторожит ОС. Поэтому достаточно именно разделения "композер"-{"рисовалка"-"тулкит+программа"}.
> Это вариант только в случае изврата когда эта рисовалка обслуживает только 1
> процесс (что больно жирно, пардон).Почему жирно? Это же форк - код разделяемый, общие данные типа шрифтов тоже разделяемы, а данные программы - свои. Самый, что ни на есть UNIX-way: mingetty, getty, login, сервера, все так поступают.
> Оно конечно да, но посмотрев на апач vs nginx я как-то за
> последнего.Я думаю, что там в другом проблема, не в fork. Те же console-helper и т.д. работают отлично.
> Судя по тому что вы активно кивали на
> тормоза оконных менеджеров, вы с такими программами просто дел не имеете
> вообще.Только с Mathematica/Matlab - всякие 3D графики.
> Они сделаны нормально. Просто неудобно как-то промышленным лазерным резаком шкуру с апельсина
> снимать. Оптимальнее взять примитивный ножик.Если резак у вас под рукой, а ножик нужно ковать и обтачивать, лучше взять резак.
> И да, опять же - вы упорно игнорируете неудобный вам топик -
> вычисляемая графика в canvas которую никакой плеер в принципе не осилит
> (если оно умеет вычисления - это что угодно но только не
> плеер уже) и прочие эффекты, являющиеся частью стандарта.Для анимации нужно менять Х, внося туда анимационные примитивы. По-видимому. Они, кстати, были.
> Если вы не заметили - обычно прикладники пишущие открытый софт как правило
> хотят юзать кроссплатформенный тулкит и не забивать себе бошку особенностями конкретных
> графических подсистем.Так это проблемы тулкитопейсателей, а не прикладушников. Мы только их и обсуждаем. А те прикладушники, которым нужен выход за рамки тулкитов должны, увы, тоже изучать графсистемы.
>> Хорошо, отконфигурьте так, чтобы был лишь ваш формат, и всуньте в инсталлятор.
>> Как-то sqlite всовываете, так почему libxine нельзя?
> Скулайт изначально заточен на встраивание и добавляет лишь 300 кило кода со
> всми наворотами. И да, когда я в последний раз видел плееры
> на основе xine они зарекомендовали себя жутко глючными.А по мне - вполне надёжными.
> И да, а что насчет canvas и прочих эффектов?
Тут, увы, придётся браузеростроителям либо остаться при своих, либо изучать граф. систему.
Но я завёл разговор про видео в FF для того, чтобы намекнуть на некоторую невменяемость браузеростроителей. Вы, конечно, упираетесь, но рисовать свой убогий видеопроигрыватель, когда есть минимум 3 отличных, готовых для встраивания - это невменяемость.
Поэтому кто знает, что они нагородили с canvas. Скорее всего, они просто под Х писать не умеют и не хотят. Слишком мала доля Х-ов. Поэтому и переход на W не поможет - его доля тоже невелика.
> Там конечно есть, НО в нем настолько много всего лишнего что попытка
> впереть его в браузер будет напоминать советский анекдот про опиловку танка
> напильником до получения формы трактора.Это значительно быстрее, чем писать самостоятельно проигрыватель.
>> А это тем кому формочек не хватило и/или захотелось эффектов.
> Такие, как показывает практика, идут стоем на ЙУХ.Это они в вашей локальной резервации идут на йух. А в моей например - я люблю симпатичные программы. И не только я.
> Всё равно, сделать компоненты красивее, чем у E17/16 не получится. А выглядеть
> будет не в пример топорнее и неудобнее.Не вижу ничего такого особого в E16/17. Ну виджеты. Обычные. Под кути и gtk есть и более симпатичные мне темы и менее. Если учесть что полезного мне софта на этих тулкитах не обнаружено, я его просто игнорирую.
> Крайне сомнительно. Почему браузеры и флеш так безбожно тормозят с видео? Скорее
> просто их бэкенды под Х сделаны через попу....потому что идеальная с точки зрения апликушника графическая подсистема должна требовать к себе минимум внимания. А вот это не про иксы с их тоннами костылей и подпорок.
> Ну нельзя же в одной бобочке 20 лет ходить. Ясен пень, что нужно рисовалку развивать.
> Но говорить, что не надо носить фуфайку из-за того, что она пачкается и портится!Ну вообще-то вы тут вроде ратовали за унифицированный вид контролов с таким нахрапом, и тут же признаете что да фиг с ним - нехай будет разнобой. Ну раз такая пьянка - пусть клиент и рендерит в своих либах. Выглядеть для юзера будет однофигственно. Зато не надо переписывать либы на которых весь популярный софт и пыжиться с разгребанием потенциально ломовой нагрузки на сервер если он сложным рендерингом займется, с антиалиасингом и прочим рендерингом векторных фонтов.
> Кроме того, вы не учитываете, что введение новых компонент сперва в офис,
> а потом в Винды - это давняя традиция MS. Я бы даже сказал, монополистическое жлобство.Офисы сроду юзают какие-то кастом-контролы которые остальным в результате в лапы вообще толком не дают. MS с удовольствием забивает на свои дизайн-гайды, наглядно показывая что это только для чернорабочих. А им, первому сорту, можно на свои же гайды с удовольствием забить. Да и вообще, свое как известно не пахнет, а доходить это начинает только когда как с IE - он теперь в рунете на 4-м месте ажно. Вот тут начинается паника и рытье окопов от забора до обеда с пониманием того что надо конкурировать, правда с непривычки совсем не понятно как это делать. Ведь делать юзеру удобно за столько лет напрочь отвыкли. А юзеры честно срулили на более удобные программы. Вот как-то так кой-кто и порастерял свое могущество в вебе...
>> разных процессов, в том числе и достаточно быстрых, работы с графикой,
>> видео, эффектами и чем там еще.
> Больше 60 ФПС человеку не нужно.Вообще, нынче иногда хорошо бы и 120. Для стерео-картинок. Но даже и 60FPS на приличных разрешениях сплюнуть в иксы стандартными методами через их обычный протокол будет проблемой. Нет, есть всякие костыли и расширения, только они где-то сбоку и зачастую опциональны и реализованы не везде. Что очень доставляет апликушникам.
>> прозрачность в том виде как это делают иксы - нужна полутора землекопам.
> Не сказал бы. Сейчас много клиент-серверных программ внутри предприятий, на локальной сети.Я думаю что клиент-серверных применений использующих именно иксовый протокол нынче не густо. А у всех остальных оно как-то устраивает а без понтов и наворотов в виде одинаковых окошек там и тут они уж как-нибудь перекантуются. Им это не главное.
> Часто делают на браузерах, хотя проще сделать через Х. Всё-таки, С++
> значительно приятнее JavaScript'a. Да и быстрее.Да, и самое издевательское - это когда яваскрипт в браузере рисующий в канвас или активно меняющий существенные части страницы начинает клинить севый код в иксах. Данная ситуация выглядит особенно тупо. Скрипт может жрать чуть ли не меньше иксов, радостно упершихся в полку на своем ядре. Во зашибись!
>> А как насчет осциллограмму снятую микроконтроллером на usb с приличным
>> FPS показать? Ну так, первое что в бошку взбрело.
> На 100 мегабитной сети легко.Да блин, хотя-бы локально. 60 FPS в нормальном разрешении? Если это делать через иксовый протокол - иксы раком встанут. По поводу чего придется сильно усложнить себе жизнь узнав о всяких расширениях где-то сбоку. А при желании еще и другим прогу раздать - можно узнать много интересного о том что вон то и се - опционально, эти драйвера на вон то кладут, в общем попадос на написание чего-то типа мплеера, с кучей подпорок. Удивительно ли что в свете такой опы все дружно юзают opengl по возможности? Он как раз мимо всего этого дурацкого протокола летит и куда резвее. Но почему кто-то должен юзать нечто ориентированное на профессиональных игроделов и тому подобные мощные 3D аппы чтобы даже простую картинку быстро выводить - я не понимаю. Это явный оверкилл.
> Я же работаю по такой сети с Математикой.
А я с ней не работаю. И еще дохрена пользовтелей - тоже.
> Именно работаю, а не мучаюсь. При этом легко работает Animate,
> перестраивает графики как на локальной машине. И это даже на извращении
> Xming, не только на Xorg'е.Как бы перестроение графиков - одно, а допустим осциллограмма с того что на входе с нормальным FPS и постоянно - уже чуть другое и предъявит уже поболее требований. И тиринг сразу нехорощим словом вспомним, и производительность будет интересовать и прочая.
> В локалке сетевая прозрачность Х со всем, кроме видео, работает.
Да, потому что видео надо нормальную производительность графической подсистемы а не тот шЫт который могут предложить иксы в дефолтовом виде без костылей с своим суперкрутым протоколом. Хотя по логике вещей, очень многим пользователям было бы удобнее если б видео нормально игралось без всяких расширений, а как там будет с сетевой прозрачностью - дело десятое. Вот в вэйланде эти приоритеты и переставили по другому. Я ж говорил что вам не понравится. Да, это менее академично и более приземленно. Маргиналам с очень кастомными затеями оно менее удобно и может создать больше проблем. Потому и ругаются :)
> Просто многие хотят и через Интернет. А когда оно, увы, обламывается, говорят "так
> не доставайся же ты никому!". И ратуют за выпиливание сетевой прозрачности.Во первых - да, если уж делать фичу, она должна нормально работать. Во вторых, это все-таки не настолько популярная фича. Во всяком случае есть достаточно пользователей которые ей не пользуются никогда. Поэтому ставить ее во главу угла концепции в ущерб остальному, более приземленному - достаточно спорная затея.
>> Ну это мы будем посмотреть. По-моему они отлично понимают то что делают.
> Тогда бы они не орали, что хотят десктоп, а там client-side-decorations. Вот
> это - чистой воды маразм!В этом мире никого не интересует степень маразматичности решения если оно работает и делает свое дело. Те кто делает вэйланд нацелились на простую мишень: сделать просто, шустро и с минимальной переделкой существующего софта. Софт уже работает как работает. Переделывать его и лежащие под ним либы - отдельный сказочный геморрой. Ибо пишется все это другими. Половина с удовольствием покажет вам и вашему концепту средний палец или покрутит пальцем у виска. На чем все и закончится. Ну вот перцы и нацелились на реалистичный и достижимый goal который можно достичь за разумное время, сделав лучше чем было с минимальными усилиями (ИЧСХ достигли чего-то работающего уже, в отличие от X12 и прочих концептуальных инициатив, которые бы потребовали намного больше времени и ресурсов). Да, ценой ряда tradeoff-ов. Не самых вкусных и нравящихся не всем. Зато реальный результат который может быть кому-то полезен за реалистичное время. "Лучше синица в руках чем журавль в небе".
>> Как по мне так трублешутить тормоза 1 программы проще чем system-wide
>> компонента и проблем меньше.
> Да ничего не будет. Сейчас же cairo не тормозит. А так она даже не будет
> делать трапеизацию всего и всея.Не тормозит если с ней ничего не делать. А если анимацию на 60FPS с размером близким к размеру экрана дуть или там гору текста рендерить оптом - вот это уже совсем не факт.
>> Это у вас он 300х300 пикселов, а у меня 800х480.
> Ну нельзя же так смешить, право слово! Я на меньше, чем на
> 1920хЧто-то стараюсь не работать. А как появятся retina по гуманной цене,
> сразу же перейду на них.У этого который 800х480 есть один убойный плюс, за которое многое можно простить: я могу его унести на край Земли на своем горбу не чертыхаясь. И энергией его могу неделю обеспечивать без розеток. А 1920хчтототам это круто, но с ним например невозможно свалить на природу отдыхать, etc. Поэтому я не против оных и за. Но считаю это не единственным сценарием. Я считаю что мне нужны системы разных калибров. И большие и маленькие.
>> Зато стало клинить мышь и вообще графику при
>> нагрузке на систему. Ноги вытащили - хвост увяз. Я что-то не
>> хочу себе систему с такими же свойствами.
> Ну тут ядро Linux с его планировщиком и nice подкачало.Это вообще-то о винде было :). Я не знаю как MS сломал то что до эторго работало, но - факт. В семерке и висте там курсор клинит злее чем на старых пингвинах. Чудеса индусской инженерии. Более того - в последних версиях линукса и графического стека эта проблема как-то сильно ослабла. Я ее на себе вообще не ощущаю. Зато попав в семерку - громко ругаюсь, ибо клинит мышь.
> Увы, не Haiku. :-( Нужно выставлять приоритет прорисовщику чуть выше,
> чем обычному процессу, и всё будет ок.Особенно ок все будет если внести туда фич потяжелее и потом рендерануть пару метров текста векторными фонтами с антиалисингом и всеми наворотами без какого либо лимитирования программ в том что они могут делать. Вот когда вообще всех остальных начнут тормозить в пользу рендеринга текста - видимо и будет ок. Но мне такая система будет искренне несимпатична. Я не лю когда у меня клинит мышь и дергается графика.
> Впрочем, планировщик Windows - это вообще патентованное гoвно - он начинает лагать,
> когда процессов становится больше, чем ядер. Поэтому может быть на Linux
> всё и обойдётся и так.Вы вообще меня неправильно прочли. И предъявили линуксу, хотя это было про винду. И да, я помню - раньше такая проблема была, анноило. Сейчас она как-то сильно ослабла и по крайней мере мышь катается нормально в большинстве случаев. Может, заслуга в развитии всяких там KMS/DRM и прочих в последнее время? Хотя это лишь предположение.
> Их и сейчас столько же, просто рисовалка внутри тулкита. А у меня даже более UNIXвейно. :-)
Да уж, и более академично. Концепт стройнее, но на практике вероятнее всего был бы полным абзацем из-за неидеальности мира, как обычно. Ну и того что пользователи математики по сети обычно страшно далеки от народа и его нужд :)
>> Вообще, я могу наблюдать тенденцию что вэйлэнд будет дружить с иксами.
> Иначе он вообще будет слит в унитаз. Он же не поддерживает без
> них ни одного коммерческого приложения под Linux. Не поддерживает ни одной
> графопостроительной программы.Узкоспециализированные графопостроительные программы нужны очень небольшому проценту пользователей. По поводу чего слит в унитаз конечто будет, но 0.1% пользователей, например. По поводу чего никто ничего и не заметит особо. Ну то-есть, 0.1% будет недоволен, зато 99.9% смогут юзать графическую систему без тормозов. И их довольство системой существенно возрастет. Выигрыш перевешивает проигрыщ. С точки зрения системостроителей ориентированных на набор и удержание пользователей а не создание суперкрутой архитектуры и правильных концепций. А поскольку программисты тоже люди и иногда могут захотеть посмотреть фильм, поиграть в игру, попользоваться браузером с современными фичами без тормозов и не хуже чем в других ОС, или хотя-бы просто захотеть написать программу выводит уйму графики в какой-то контрол в реалтайме. Будь оно анализатор спектра, осциллограф, показометр или что там еще, где желательна быстрая перерисовка существенной области, в том числе и битмаповой но совсем не желательно таскать с собой столько костылей и подпорок сколько это делают "полновесные плееры видео".
>> Да, однако это не значит что времена выполнения запросов программ поделятся нормально.
>> По крайней мере если не городить ужас с персональым процессом-спутником или
>> крутой арбитр ресурсов.
> Почему? Зачем арбит? Рисовалка отдаёт битмап композеру - это быстро, а когда
> рисует - долгий процесс, её сторожит ОС. Поэтому достаточно именно разделения
> "композер"-{"рисовалка"-"тулкит+программа"}.Проблема в том что распределение ресурсов рендерера между программами никак не контролируется. Выдавать каждой программе по персональному рендереру - выглядит довольно расточительно по ресурсам, особенно если рендерер сложный и жирный. А если это какой-то общий компонент, да еще способный к деланию тяжелой работы - всегда есть шанс что некая программа вгрузит в него вгрузит изрядно работы. И пока он ее будет жевать - "и пусть весь мир подождет". А вот пользователю не понравится что остальные программы курят бамбук пока некая особо умная программа усиленно рендерит 20 метров текста векторными фонтами. В этом плане то как оно сейчас - далеко не самый плохой вариант. В том плане что никаких лишних процессов, шаред либы тулкитов в 1 копии в памяти и копируются только отличия, а попытка отрендерить 20 метров текста векторным фонтом на скорость - клинит исключительно самого виновника торжества. Ну и пусть себе висит наздоровье. Чертыхнемся и переключимся в другого. А вот если это вызовет общесистемные проблемы и тормоза - это уже плохо.
> Почему жирно? Это же форк - код разделяемый, общие данные типа шрифтов
> тоже разделяемы, а данные программы - свои.И тем не менее, как показывает пример апача, и старт форка занимает вполне себе некое время, и ресурсов оно вполне себе кушает. В общем мне в системе не нужен "апач от графической системы", уж извините.
> Самый, что ни на есть UNIX-way: mingetty, getty, login, сервера, все так поступают.
Есть очень умная поговорка: все хорошо в меру. Вот и форки - тоже. Срач в системе процессами-спутниками на каждый процесс - это явный оверкилл. Ну то-есть вы конечно можете пользоваться такими дизайнами если вы считаете это правильно, а я как-нибудь пешком постою и поюзаю нечто с более вменяемым дизайном. Любую идею можно довести до абсурда. Даже форки. Вот форк процесса-спутника на каждый процесс - это оно самое.
>> Оно конечно да, но посмотрев на апач vs nginx я как-то за последнего.
> Я думаю, что там в другом проблема, не в fork.В ряде случаев - и в нем тоже. И память оно умеет жрать прилично. В общем форк это хорошо. А вот злоупотребление оным - хреново и потенциально может вызывать проблемы.
> Те же console-helper и т.д. работают отлично.
Так на них и нагрузка не такая как на графическую систему и их немного. Форк ничем таким не плох, если его в меру. Но форкать процесс-спутник каждому процессу выводящему графику - явный перебор. Вот еще не хватало какому-то вшивому индикатору температуры проца в трее здоровый процесс-спутник раскочегаривать. Хвост виляет собакой!
>> Судя по тому что вы активно кивали на тормоза оконных менеджеров,
>> вы с такими программами просто дел не имеете вообще.
> Только с Mathematica/Matlab - всякие 3D графики.Я не думаю что они сильно активно лупят перерисовку графиков в объеме который мог бы напрягать. А вот например хоть тот же спектроанализатор аудиоплеера или приблуда типа осциллографа - на стандартном иксовом протоколе будет очень не фонтан. Вот и получается что какой-то вшивый спектроанализатор должен стать чуть ли не mplayer-ом в плане вывода графики.
>> снимать. Оптимальнее взять примитивный ножик.
> Если резак у вас под рукой, а ножик нужно ковать и обтачивать, лучше взять резак.Еще спорный вопрос что быстрее будет. Нормальный человек почертыхается и руками шкуру с апельсина отдерет. Маньяк будет неделю писать концептуальную программу очистки апельсина лазером, изведет мешок апельсинов для тестов и так далее. Несомненно, круто и технологично и вызывает отвал челюсти у любого увидевшего. Но в реальной жизни ценность такого решения около нуля. Ну нет у типового покупателя апельсина такого резака. А у тех у кого он есть - это далеко не самое эффективное применение данной машины.
>> (если оно умеет вычисления - это что угодно но только не
>> плеер уже) и прочие эффекты, являющиеся частью стандарта.
> Для анимации нужно менять Х, внося туда анимационные примитивы. По-видимому. Они,
> кстати, были.Я бы даже сказал что не столько анимация, сколько "вычисляемая графика". Анимация - да, ее можно заранее вгрузить. Но для canvas, спектроанализаторов, осциллоскопов, показометров, ряда и прочая вгрузить анимацию заранее - не прокатит. Надо чтобы прсото быстро работал вывод графики.
> Так это проблемы тулкитопейсателей, а не прикладушников.
А они тоже хотят поддерживать кучу систем и им не резон сильно мучаться с особенностями каждой графической подсистемы.
> Мы только их и обсуждаем. А те прикладушники, которым нужен выход за рамки
> тулкитов должны, увы, тоже изучать графсистемы.Вот хорошая граф.система должна работать, делать свое дело и требовать к себе абсолютный минимум внимания. Иначе ее будут всеми силами избегать и не будут на нее ничего портировать. Кто же хочет себе дофига геморроя на бошку? Особенно ради осчастливливания 0.1% юзерей с какими-то специфичными задачами.
>> на основе xine они зарекомендовали себя жутко глючными.
> А по мне - вполне надёжными.Ну не знаю, мне с плеерами юзающими xine как-то не везло: они с грохотом валились на самых обычных файлах которые остальные играют. Сильно разбираться не стал и просто поюзал плееры которые этим не страдают, т.е. vlc и mplayer. Потому что у меня нет самоцели жрать конкретный сорт кактусов. Учтя что браузер заведомо имеет дело с внешними данными скроенными абы как (а потенциально еще и хакерские эксплойты бывают, где данные специально кривые) - меня как-то не устроит такая "надежность".
>> И да, а что насчет canvas и прочих эффектов?
> Тут, увы, придётся браузеростроителям либо остаться при своих, либо изучать граф. систему.Ну вот они и сделали так как проще им. В ущерб пользователям иксов слегонца. У пользователей соответственно есть поводы не жаловать иксы. За отсутствие стандартных mandatory методов не выбивающихся за обычное апи потребных для быстрого вывода графики.
> Но я завёл разговор про видео в FF для того, чтобы намекнуть
> на некоторую невменяемость браузеростроителей.Они как раз вполне вменяемы. Просто они пекутся об удобстве своих задниц и о том как с минимальными затратами ресурсов осчастливить побольше разных пользователей. А сильно рвать зад и лезть в дебри ради 0.1% всякой экзотики никто не будет. Будете настаивать - скажут что "unsupported" и досвидания.
> Вы, конечно, упираетесь, но рисовать свой убогий видеопроигрыватель,
У него есть ряд специальных требований, из-за которых использовать уже существующие плееры может оказаться даже более проблематично нежели написать мелкий, специализированный. И да, если что - я юзал плагины встраивающие мплеер или vlc в мозиллу. Для веба это скажем так, работает очень дубово и криво. Нативный браузерный плеер не в пример приятнее. И не выглядит как бельмо на глазу, и вебпаги могут своим видео рулить так как задумано авторами, и стиль контролов плеера можно под остальное оформление сайта подогнать. А упомянутое есть, пашет, но выглядит как чужеродный элемент страницы - FAIL.
> когда есть минимум 3 отличных, готовых для встраивания - это невменяемость.
Только если не учитывать их goals и специфичные требования к плееру.
> Поэтому кто знает, что они нагородили с canvas. Скорее всего, они просто
> под Х писать не умеют и не хотят. Слишком мала доля Х-ов. Поэтому и переход
> на W не поможет - его доля тоже невелика.А от W и не требуется "помогать". Его дело - не мешать. То-есть если некто рисует в канвасе, дело графической подсистемы при этом всего лишь максимально быстро сплюнуть это на экран и не выпендриваться.
> Это значительно быстрее, чем писать самостоятельно проигрыватель.
С учетом специфичных требований и того что танк изначально не совсем похож на трактор - не факт, напильник потребуется изрядный.
> Это они в вашей локальной резервации идут на йух. А в моей
> например - я люблю симпатичные программы. И не только я.Практика показывает, что те, кто делает невписывающиеся в граф. систему программы, как правило, делают их крайне уныло. Да и вообще, мне казалось, что этим ещё в 90-е переболели, на Windows 9x.
> ...потому что идеальная с точки зрения апликушника графическая подсистема должна требовать
> к себе минимум внимания. А вот это не про иксы с
> их тоннами костылей и подпорок.Да, Х надо реформировать. Я не отрицаю. Только в направлении, противоположном W.
> Ну вообще-то вы тут вроде ратовали за унифицированный вид контролов с таким
> нахрапом, и тут же признаете что да фиг с ним -
> нехай будет разнобой.Скажем так, от наличия разных тулкитов уже не уйти, видимо. Но вот хоть заголовки-то разными не надо делать! В смысле, так не особо вид консистентный, но давайте уж не будем его дальше портить.
> Офисы сроду юзают какие-то кастом-контролы которые остальным в результате в лапы вообще
> толком не дают.Ну многие всё-таки выдают - закладки в диалогах (TAB), 3D вид (Word 6), ribbon. Хотя, конечно, жлобство наличиствует.
> MS с удовольствием забивает на свои дизайн-гайды, наглядно
> показывая что это только для чернорабочих.Ну так за то и ценят Apple - за жестокость к своим и чужим.
> Ведь делать юзеру удобно за столько лет
> напрочь отвыкли.Да MS никогда не умели. Вы посмотрите - всё же сделано неудобно: консоль - дрянь, WM - дрянь, браузер - дрянь. Всё вроде бы и сделано, и работает, и неудобно. Просто всё. Я не знаю, когда Windows были удобны.
> Я думаю что клиент-серверных применений использующих именно иксовый протокол нынче не густо.
Ну я прямо сейчас так работаю. Именно работаю, а не мучаюсь с VNC.
> Да, и самое издевательское - это когда яваскрипт в браузере рисующий в
> канвас или активно меняющий существенные части страницы начинает клинить севый код
> в иксах.Ну браузер через сетевые Х пробрасывать не рекомендуется. А то, что JS часто клинит - так это я на Windows регулярно наблюдаю. Там-то хоть это не из-за сетевого кода Х?
>>> А как насчет осциллограмму снятую микроконтроллером на usb с приличным
>>> FPS показать? Ну так, первое что в бошку взбрело.
>> На 100 мегабитной сети легко.
> Да блин, хотя-бы локально.Мне кажется, что локально должно вполне легко показываться. У меня Mathematica строит анимации свободно с помощью Qt отрисовщика. Графики анимируются - т.е перерисовываются в виде мультика.
> Как бы перестроение графиков - одно, а допустим осциллограмма с того что
> на входе с нормальным FPS и постоянно - уже чуть другое
> и предъявит уже поболее требований. И тиринг сразу нехорощим словом вспомним,
> и производительность будет интересовать и прочая.Осциллограмма, кстати, как правило, стоит - нужно же сигнал синхронизации настроить правильно.
>> В локалке сетевая прозрачность Х со всем, кроме видео, работает.
> Да, потому что видео надо нормальную производительность графической подсистемыНет, потому, что видео по сети нужно гнать в сжатом виде.
> Во первых - да, если уж делать фичу, она должна нормально работать.
Она нормально работает, просто у неё есть определённые требования к сети.
> Во вторых, это все-таки не настолько популярная фича. Во всяком случае
> есть достаточно пользователей которые ей не пользуются никогда.Кириллицей тоже почти никто не пользуется. Выпиливаем?
> В этом мире никого не интересует степень маразматичности решения если оно работает
> и делает свое дело.Оно не работает. Я НИГДЕ, ни в одной ВЗЛЕТЕВШЕЙ системе не видел client-side-decorations. Поэтому отставить.
> Зато реальный результат который
> может быть кому-то полезен за реалистичное время. "Лучше синица в руках
> чем журавль в небе".Реальный результат - это НЕ делать Wayland. Ибо он ЯВНО добавляет проблемы. А вот уж решает он их или нет - неизвестно. Потому выкинуть Wayland сейчас ЛУЧШЕ, чем выкинуть его через ещё один год разработки.
> У этого который 800х480 есть один убойный плюс, за которое многое можно
> простить: я могу его унести на край Земли на своем горбу
> не чертыхаясь.Я очень рад. Но почему обязательно нужно в 21м веке на 24-х дюймовом мониторе наблюдать артефакты 800х480. Давным давно нужно было перейти на вектор.
> Это вообще-то о винде было :).
Планировщик Linux - это переходный этап от WinNT к Haiku. ;-) Поэтому сдюжит он или нет - непонятно.
>> Увы, не Haiku. :-( Нужно выставлять приоритет прорисовщику чуть выше,
>> чем обычному процессу, и всё будет ок.
> Особенно ок все будет если внести туда фич потяжелее и потом рендерануть
> пару метров текста векторными фонтами с антиалисингом и всеми наворотами без
> какого либо лимитирования программ в том что они могут делать. Вот
> когда вообще всех остальных начнут тормозить в пользу рендеринга текста -
> видимо и будет ок. Но мне такая система будет искренне несимпатична.Вообще-то, даже в древнем UNIX минимум 20-ть приоритетов. И отзывчивая система получается просто правильной их расстоновкой.
> Вы вообще меня неправильно прочли. И предъявили линуксу, хотя это было про
> винду.Я правильно прочёл. В Linux тоже не идеально, хотя и значительно лучше.
> И да, я помню - раньше такая проблема была, анноило.
> Сейчас она как-то сильно ослабла и по крайней мере мышь катается
> нормально в большинстве случаев. Может, заслуга в развитии всяких там KMS/DRM
> и прочих в последнее время? Хотя это лишь предположение.Насколько я слышал, просто повысили приоритет нужного процесса. Хотя, может быть, я ошибаюсь.
> Да уж, и более академично. Концепт стройнее, но на практике вероятнее всего
> был бы полным абзацем из-за неидеальности мира, как обычно. Ну и
> того что пользователи математики по сети обычно страшно далеки от народа
> и его нужд :)
> Узкоспециализированные графопостроительные программы нужны очень небольшому проценту
> пользователей. По поводу чего слит в унитаз конечто будет, но 0.1%
> пользователей, например.Linux имеет огромную пользовательскую базу в университетах, где его любят и пользуются им (50% и больше машин). В других местах он значительно менее популярен. В университетах есть всё, что я перечислил.
> Выдавать каждой программе по персональному рендереру - выглядит довольно расточительно
> по ресурсам, особенно если рендерер сложный и жирный.Если это форки одного процесса, то почему? Ну он один раз запустился и всё. Главное, чтобы память на форк тратилась не сильно, но это вроде бы возможно. В общем, я не вижу особых проблем, если сделать разумно.
Кстати, время на форк тут значительно менее критично, чем у апача - один рисовальщик стартует вместе с программой, а не web-запросом. То есть, частота форков на пару порядков ниже.
Пи___ц портянки накатали.
Обменяйтесь уже жабрами, да общайтесь там.
Сомневаюсь, что кто-то кроме вас двоих читает эти продукты вашего графоманства.
> Пи___ц портянки накатали.Гражданин, вас тут не задерживают. Хотите - читайте, не хотите - не читайте. Всё просто.
> Обменяйтесь уже жабрами, да общайтесь там.
Не говорите, что нам делать, и мы не скажем, куда вам идти.
> Сомневаюсь, что кто-то кроме вас двоих читает эти продукты вашего графоманства.
И что с этого?
> А мне кажется что графическая система должна просто быстро выводить битмапы обсчитанные
> программой и не выпендриваться.вот скажи: у тебя же — вроде бы — мозги есть. даже работают. я тебе прямым текстом говорил: не лезь в обсуждение графических систем, ну не лезь. не понимаешь ты в них ничего ниже уровня «аааа, я видел тиринг!!!» и «ааааа, я видел, как пара кривософтов их затормозила!!!» и на основе этой ерунды ты делаешь «выводы», вполне достойные по качеству вани-однобитного-флоата.
> HTML5 подразумевает HTMLные контролы для управления + их доступность из JS
> и что там еще, что малость неудобно реализовать в таковых условиях.бедные, бедные авторы морд к mplayer! у них сидят 100500 обученых рабов, которые днями и ночами реализуют и OSD, и контролы поверх видео.
ты снова полез туда, где ничего не понимаешь. встраивание mplayer в софтины — это один из *штатных* сценариев его использования. и создание поверх него своих контролов, OSD, чертей с вилами — не чёрная магия, а тоже вполне несложные штатные действия. и для этого — О, ЧУДО! — даже не надо постоянно пересобирать mplayer из исходников, а достаточно взять штатный из системного пакета.
Первоквака по сети вытаскивалась с сана на обычный комп, конец 90-х. А теперь, через лет пятнадцать, у ламеров криворуких ботлнеки появились.
> Первоквака по сети вытаскивалась с сана на обычный комп, конец 90-х. А
> теперь, через лет пятнадцать, у ламеров криворуких ботлнеки появились.А теперь, лет через 15, требования к графике как-то поболее чем в конце 90-х и квейк с быстрого сервака по быстрой сети в разрешении с кошкину попу никого не удивляет.
А сможете пробросить ну хотя-бы xonotic в fullHD? Ну хоть на 75FPS? Это как-то в 2012 году более актуально.
гл по сети нормально не прокидывается?? тогда в чём тебе вяленый тут поможет?
> гл по сети нормально не прокидывается?? тогда в чём тебе вяленый тут поможет?Ничем. Зато он будет заметно меньше мешаться на пути вывода графики из апликух.
> иксами и тулкитами для смартфонов и прочей 320 на 300 дряни.А вывод активно меняющейся картинки через стандартные дефолтные апи иксов - ну совсем не тормозит, ну конечно. Правда иксы имеют тенденцию жрать при этом 1 ядро проца в полку, но кого это волнует... :)
>> иксами и тулкитами для смартфонов и прочей 320 на 300 дряни.
> А вывод активно меняющейся картинки через стандартные дефолтные апи иксов - ну
> совсем не тормозит, ну конечно. Правда иксы имеют тенденцию жрать при
> этом 1 ядро проца в полку, но кого это волнует... :)А чего, разве не для этого вы все так рвались получить свои многоядерники? Они так-то не простаивать должны. В теории-то!
> А чего, разве не для этого вы все так рвались получить свои
> многоядерники? Они так-то не простаивать должны. В теории-то!Так это... если оно уперлось в полку, вывод графики начинает лимитироваться иксами. А вот это уже FAIL.
> А кому-нибудь попадалось описание полного стека, который они предлагают на замену иксам?
> Там вообще кто-то цельную конструкцию этого стека в голове держит?есть описание стека X-ов с его расширениями и зачем нужен wayland http://habrahabr.ru/post/148954/
live cd: http://sourceforge.net/projects/rebeccablackos/
А МАТЕ будет работать?
двачую вопрос
>Из планов на будущее отмечается подготовка прослойки для обеспечения сетевой прозрачности, учёт MIME-типов при манипуляции данными через буфер обмена и механизм drag&drop, создание протокола для управления элементами декорации окон (назначение заголовка и размещение кнопок закрытия/сворачивания), определение логики работы с всплывающими окнами, поддержка синхронного вывода изображений на несколько мониторов, возможность предоставления совместного доступа к буферам для клиента, создания протокола для управления настройками (темы оформления, параметры шрифтов и т.п.).Я идиот, или с введением всего этого Wayland станет равнозначен некоему подмножеству X? Не легче ли было просто объявить в Х устаревшими векторные операции, и через пару релизов выкинуть реализующий их код?
Ну, там еще примерно такой же списочек надо быдет реализовать - но да, конечно. Просто вместо нормального проектирования архитектуры будет очередное "само выросло". Но забавно всё же - вот уже и централизованное управление декорациями появляется, и темы выносятся в общую конфигурацию, и сетевую прозрачность хотят стандартную делать (хотя лучше б она на вер\кторе была, конечно)... А как открещивались.
> (хотя лучше б она на вер\кторе была, конечно)Лучьше, да. Только, cегодня работает OpenGL (c). Даже в тестовых утилитах вяленда, навроде консоли или ещё чего, во всю юзается аппаратный рендеринг. cairo-gl, да. Да и с зоопарком тулкитов, такое наврятли возможно добится. У каждого свой, супер-навороченный рендер, и с этим ничего не поделаешь.
Ну вот суём этот самый cairo в иксы ещё одним расширением. Общение с ним весьма непрожорливо по ресурсам. И всё, вуаля - сохранили векторный протокол и получили простор для оптимизаций на стороне сервера, детально знающего, какое у нас железо и что умеет.
А вот как убедить остальных не плодить велосипеды - не знаю. Может и никак, учитывая, что они стараются кроссплатформенными быть.
был такой проект xgl, что-то не взлетел. догадайтесь что за фирма продвинула конкурирующие решение.
> Я идиот, или с введением всего этого Wayland станет равнозначен некоему подмножеству
> X?Станет, конечно. Т.к. Х, как известно, делают всё, что будет делать W, и ещё немножко. :-)
> Не легче ли было просто объявить в Х устаревшими векторные
> операции, и через пару релизов выкинуть реализующий их код?Скорее надо наоборот, внести векторные операции из рендеров Gtk/Qt. ;-) Чтобы не делать 10 велосипедов, по одному в каждой библиотеке тулкитов.
> Скорее надо наоборот, внести векторные операции из рендеров Gtk/Qt. ;-) Чтобы не
> делать 10 велосипедов, по одному в каждой библиотеке тулкитов.Осталась сущая фигня - найти этого рыцаря на белом коне который избавит мир от велосипедов, построит всех негодяев переизобретающих оные и так далее.
>> Скорее надо наоборот, внести векторные операции из рендеров Gtk/Qt. ;-) Чтобы не
>> делать 10 велосипедов, по одному в каждой библиотеке тулкитов.
> Осталась сущая фигня - найти этого рыцаря на белом коне который избавит
> мир от велосипедов, построит всех негодяев переизобретающих оные и так далее.Большинство "негодяев" счастливы будут избавиться от таскания/поддержки графической бибилиотеки. Основная проблема - что поезд идёт в другую сторону и даже представь сейчас готовую реализацию - задолбаешься убеждать товарищей, коотрые сетевую прозрачность в гробу видели.
> задолбаешься убеждать товарищей, коотрые сетевую прозрачность в гробу видели.Такое ощущение, что им если дашь нормальную систему с прекрасно работающей сетевой прозрачностью они её из принципа отдерут. Ибо "зачем? 1% использует".
Если посмотреть на ту же OpenNet'овскую страничку, станет очевидно, что для её прорисовки с нормальными графическими примитивами нужно дай бог килобайт данных передать от клиента к серверу + битмап шапки передать. Это сущие копейки на современных локалках.
> Такое ощущение, что им если дашь нормальную систему с прекрасно работающей сетевой
> прозрачностью они её из принципа отдерут.В лично моем понимании это должно быть чем-то типа плагина/расширения. Вгружать 100% юзеров код которым будет пользоваться 1% с ножом к горлу - не есть правильно. Ну или если вы такой щедрый - ой, а давайте я у вас дома пару мешков картощки и штабель кирпичей похраню пару годиков, а? Ну или почему вам можно превращать мой винт в склад байтов для вас, а мне вашу хату - нельзя?
> В лично моем понимании это должно быть чем-то типа плагина/расширения.Все оконные системы строятся на механизме посылки сообщений. Поэтому соответствующие примитивы, которые отрисовывает графический движок (XServer/GDI/GDI+/...), должны быть достаточно удобны. Удобны - это значит, в типичное приложение отсылает минимум этих примитивов на прорисовку.
Поэтому, если набор примитивов выбран правильно, трафик команд от приложения к отрисовщику смешной для современных сетей. И, соответственно, сетевая прозрачность у вас получается совершенно бесплатно. :-)
Лучше всего, конечно, иметь несколько транспортов от приложения к отрисовщику, как сейчас в X. ;-)
---------------------------
Проблема в текущих Х в том, что в качестве отрисовщика "antialiased" фигур выбран XRender - расширение с крайне неудачным набором примитивов. Это расширение умеет отрисовывать только трапеции, поэтому библиотекам Qt/Gtk приходится раскладывать свои удобные и хорошие примитивы в трапеции. И слать эти дикие наборы трапеций по сети.Соответственно, нужно убрать XRender, заменив его на что-то более вменяемое. Типа растеризатора QPainter или Cairo.
> Все оконные системы строятся на механизме посылки сообщений.С точки зрения апликушников - они меньше всего хотят что-либо знать про весь этот кошмар и копаться в нем, предпочитая дерг платформо-нейтральных либ типа GTK или Qt. А вот оным для кроссплатформенности не получится сильно уповать на возможности конкретной графической подсистемы в ущерб остальным. Наверное что-то такое и мотивирует авторов подобных либ не выносить рендер контролов в сервер. Который разный и есть не везде. Пардон, куть или гтк могут в принципе рендерить даже в тупой фреймбуфер если оно надо. А кто такое там графический сервер? А вот софт работает. Иногда это сильно упрощает дизайн систем.
> Поэтому соответствующие примитивы, которые отрисовывает графический движок
> (XServer/GDI/GDI+/...), должны быть достаточно удобны. Удобны - это значит, в типичное приложение отсылает минимум этих
> примитивов на прорисовку.И получится очередная винда, где все прибито гвоздями. Впрочем и там - разброд и шатания. WPF и WinForms нынче как-то сватают вместо GDI. И это понятно - GDI в чистом виде на редкость невкусная для прикладников штука.
> Поэтому, если набор примитивов выбран правильно, трафик команд от приложения к отрисовщику
> смешной для современных сетей.Понимаете ли, для вас на гигабитном эзернете он может смешной, а для Васи Пупкина с жпрс - он очень даже серьезный. И какой-нибудь rdp там будет работать не в пример лучше. Хоть оно насколько я понимаю и по сути лишь синхронизация битмапов ремотно и локально путем передачи межкадровой дельты. Тупо, топорно, концептуально кривее. Но в этом мире на практике а не в теории сие работает намного лучше.
> И, соответственно, сетевая прозрачность у вас получается совершенно бесплатно. :-)
Пока как-то не заметно. Я конечно понимаю что проблемы негров шерифа не волнуют, но в случае если негр стал президентом, ситуация меняется на обратную, увы :)
> Лучше всего, конечно, иметь несколько транспортов от приложения к отрисовщику,
Как по мне так это вообще заявка на лишний оверхед.
> умеет отрисовывать только трапеции, поэтому библиотекам Qt/Gtk приходится раскладывать
> свои удобные и хорошие примитивы в трапеции. И слать эти дикие наборы трапеций по сети.А как насчет быстрого вывода битовых карт оптом, не опционально и сбоку, а сразу и гарантированно? А пересылки только дельты по сети?
> Соответственно, нужно убрать XRender, заменив его на что-то более вменяемое. Типа растеризатора
> QPainter или Cairo.Никак не адресует проблему с тем что все больше приложений желают эффекты/анимации/хардкорный рендер всего и вся. Например, должна ли читалка PDF вгружать фонты в сервер и заставлять его рендерить это или же нехай сама рендерит? В конечном итоге - все идет к тому что сама рендерит.
> Как по мне так это вообще заявка на лишний оверхед.Это не узкое место системы.
> Понимаете ли, для вас на гигабитном эзернете он может смешной, а для Васи Пупкина с жпрс - он очень даже серьезный. И какой-нибудь rdp там будет работать не в пример лучше.
RDP - это как раз не битмапы. Это совершенно X-овый подход, просто сделанный значительно лучше нынешнего состояния Х.
> Например, должна ли читалка PDF вгружать фонты в сервер и заставлять его рендерить это или же нехай сама рендерит? В конечном итоге - все идет к тому что сама рендерит.
Читалка PDF - это отдельный совершенно разговор: она должна представлять документ совершенно единым способом. А вот большая часть программ должна прорисовываться именно теми шрифтами, что выбраны на X Сервере - той машине, с которой работает пользователь.
> Это не узкое место системы....до тех пор пока какой-нибудь козел не решит что отрендерить мег текста векторными фонтами с максимальным качеством - это здорово. При том это проще чем кажется. Необдуманный cat в графической терминалке - и вот уже наш мег текста усиленно рендерится терминалкой на максимальной скорости, как с куста. Как-то хреново будет если от этого будет клинить вообще весь сервер графики надрывающийся на рендер мегазов текста векторными фонтами.
> RDP - это как раз не битмапы. Это совершенно X-овый подход, просто
> сделанный значительно лучше нынешнего состояния Х.А зачем там тогда есть битмап-кэш, позволяющий снизить траффик и хранящий текущий кадр? Характерное такое файло немелкого размера с текущим буфером кадра. И да, не хочу ничего сказать но rfp посылает именно ремотный рендеринг. То-есть, окна и контролы - выглядят как именно на ремотной машине. Да, это вызывает некий диссонанс, но с друго стороны это и баг и фича. Совсем терять грань между локалью и ремотой чревато большим обломом при отключении от сети.
> шрифтами, что выбраны на X Сервере - той машине, с которой
> работает пользователь.Вот только лично мне идея простого и легкого сервера который фиг заклинишь нравится больше. В целом я полагаю что намного лучше если ресурсоемкие операции будут уделом программ. Их так и полисовать проще и system-wide bottleneck-ов не будет возникать.
> Как-то хреново будет если от этого будет клинить вообще
> весь сервер графики надрывающийся на рендер мегазов текста векторными фонтами.Значит для каждой программы у рендера должен быть свой процесс. Но не свой код рендера, как сейчас. :-)
> А зачем там тогда есть битмап-кэш, позволяющий снизить траффик и хранящий текущий
> кадр?Потому, что RDP умные люди делали. :-) У RDP основной рендер - векторный, но есть ещё и возможность перекидывания битмапов.
> То-есть, окна и контролы - выглядят как именно на ремотной машине.
> Да, это вызывает некий диссонанс, но с друго стороны это и
> баг и фича. Совсем терять грань между локалью и ремотой чревато
> большим обломом при отключении от сети.После того, как вы посидите за машиной, где удалённые программы выглядят как родные, от вышеописанного вас будет тянуть блевать. :-)
Всё-таки, изначально X проектировали ещё более умные люди, чем те, что делали RDP. ;-)
> Значит для каждой программы у рендера должен быть свой процесс. Но не
> свой код рендера, как сейчас. :-)Не, спасибо, не люблю апаче-стайл решения, когда проблемы программеров сбагриваются на юзерей.
> векторный, но есть ещё и возможность перекидывания битмапов.
Опять же, а зачем там например настройки упрощения картинки типа более дубовых заголовков окон? Я так понимаю что при этом оно лучше жмется. Хотя сильно спорить не буду, прсото указанные признаки явно указывают на умение слать дельту между кадрами как жатый битмап и что этому уделили много внимания. И получше чем в VNC например, как я понимаю.
> После того, как вы посидите за машиной, где удалённые программы выглядят как
> родные, от вышеописанного вас будет тянуть блевать. :-)Я люблю четко понимать где у меня что. Где местное а где сетевое, которое just in case отвалиться может.
> Всё-таки, изначально X проектировали ещё более умные люди, чем те, что делали RDP. ;-)
Да блин, все академики в этом - задумают крЮтой концепт, а то что он на практике еле ползает - их мало интересует. А потом приходит инженер и показывает как из г-на и палок с проектированием "по месту" получается в три раза более хорощий по пользовательским свойствам результат. Хоть архитектура и полный крап.
> Хотя сильно спорить не буду, прсото указанные признаки явно указывают на
> умение слать дельту между кадрами как жатый битмап и что этому
> уделили много внимания. И получше чем в VNC например, как я
> понимаю.Оно умеет и битмап, и команды GDI. Просто без вектора не сделать нормальную систему, за которой можно работать. На битмапах только аварийный вход типа VNC.
>> После того, как вы посидите за машиной, где удалённые программы выглядят как
>> родные, от вышеописанного вас будет тянуть блевать. :-)
> Я люблю четко понимать где у меня что. Где местное а где
> сетевое, которое just in case отвалиться может.А я - нет. У меня сеть втыкнута шнуром и отвалиться не может. Кроме того, можно же в заголовке писать - откуда, а не ставить уродские шрифты. :-)
>> Всё-таки, изначально X проектировали ещё более умные люди, чем те, что делали RDP. ;-)
> Да блин, все академики в этом - задумают крЮтой концепт, а то
> что он на практике еле ползает - их мало интересует.Когда академики трогали Х, тогда всё летало. :-) А вот как пыонэры начали корёжить, так и поплыла штучка.
> Оно умеет и битмап, и команды GDI.А что есть "команды GDI" в случае допустим xrdp?
> Просто без вектора не сделать нормальную систему,
> за которой можно работать. На битмапах только аварийный вход типа VNC.Хм... мне все-таки интересно, а это где-то документировано? Насчет GDI и прочая... откуда эти сведения?
>> Я люблю четко понимать где у меня что. Где местное а где
>> сетевое, которое just in case отвалиться может.
> А я - нет. У меня сеть втыкнута шнуром и отвалиться не может.Я как-то не против десктопа. Но у меня есть еще и ноут и мобилка. Они умеют ходить по rdp/vnc/ssh/whatever else. И могут использоваться с беспроводными интерфейсами. А почему, собственно, мне должно быть нельзя зайти на мой десктоп из другого города, например?
> Кроме того, можно же в заголовке писать - откуда, а не ставить уродские шрифты. :-)
Ну вообще да. Еще можно что-то типа того что у рутковской. Но упомянутое получается нахаляву с нулевыми затратами сил -> баг является и фичой, в зависимости от ситуации :)
>> Да блин, все академики в этом - задумают крЮтой концепт, а то
>> что он на практике еле ползает - их мало интересует.
> Когда академики трогали Х, тогда всё летало. :-)Тогда мир был другим. Constraints были иными. А том чтобы на компьютере видео смотреть тогда речь вообще не шла.
> А вот как пыонэры начали корёжить, так и поплыла штучка.
Так от хорошей жизни никто не начинает корежить, знаете ли. Корежат обычно если хочется чтобы оно могло так и эдак а оно еще не умеет.
>> Оно умеет и битмап, и команды GDI.
> А что есть "команды GDI" в случае допустим xrdp?В системе MS Windows есть несколько рисовалок, в том числе GDI и GDI+. У этих рисовалок есть свои примитивы, которые, к примеру, записываются в метафайлы. Вот о них и речь. От rdp клиента набор этих примитивов не зависит.
> Хм... мне все-таки интересно, а это где-то документировано? Насчет GDI и прочая...
> откуда эти сведения?http://msdn.microsoft.com/en-us/library/cc239611%28prot...
"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."
Это, собственно, и есть подход X Window System, как её проектировали умные дядьки в MIT, DEC и IBM.
> Я как-то не против десктопа. Но у меня есть еще и ноут
> и мобилка. Они умеют ходить по rdp/vnc/ssh/whatever else. И могут использоваться
> с беспроводными интерфейсами. А почему, собственно, мне должно быть нельзя зайти
> на мой десктоп из другого города, например?Можно, но лучше оформлять удалённость программы аккуратной пометкой в заголовке окна (такое Х умеют делать), а не уродскими шрифтами, о которые вы будете ломать глаза (они хорошие, просто отрисованы для другого DPI).
> Тогда мир был другим. Constraints были иными. А том чтобы на компьютере
> видео смотреть тогда речь вообще не шла.Ну, если бы умные люди того же уровня (DEC+MIT) взялись бы за Х, то они бы и видео наладили.
> Так от хорошей жизни никто не начинает корежить, знаете ли. Корежат обычно
> если хочется чтобы оно могло так и эдак а оно еще
> не умеет.Там была проблема в том, что Х изначально не поддерживали anti-aliasing. Но вместо того, чтобы его просто ввести в сервер, сделали кучу всего дурного. :-(
> Это, собственно, и есть подход X Window System, как её проектировали умные дядьки в MIT, DEC и IBM.И по русски тоже самое http://www.securitylab.ru/analytics/367591.php
>[оверквотинг удален]
>> Тогда мир был другим. Constraints были иными. А том чтобы на компьютере
>> видео смотреть тогда речь вообще не шла.
> Ну, если бы умные люди того же уровня (DEC+MIT) взялись бы за
> Х, то они бы и видео наладили.
>> Так от хорошей жизни никто не начинает корежить, знаете ли. Корежат обычно
>> если хочется чтобы оно могло так и эдак а оно еще
>> не умеет.
> Там была проблема в том, что Х изначально не поддерживали anti-aliasing. Но
> вместо того, чтобы его просто ввести в сервер, сделали кучу всего
> дурного. :-(anti-aliasing - Оно хоть где-нибудь, кроме Теслы и Ферми, быстро работает? Ну то есть хотя бы с приемлемой скоростью?
> anti-aliasing - Оно хоть где-нибудь, кроме Теслы и Ферми, быстро работает? Ну
> то есть хотя бы с приемлемой скоростью?Работает, но ресурсов - жрет прилично. А вон тот гражданин предлагает его в иксы.
>> anti-aliasing - Оно хоть где-нибудь, кроме Теслы и Ферми, быстро работает? Ну
>> то есть хотя бы с приемлемой скоростью?
> Работает, но ресурсов - жрет прилично. А вон тот гражданин предлагает его
> в иксы.Он сбрендил. Там считанины реального времени конское количество. Без аппаратной поддержки это вообще будет медленно и печально. И это мягко говоря. 1-2 fps.
И много ты видел _современных_ DE, у которых окна и контролы - зафиленные ректанглы, а бекграунды - $color_name?
> даже представь сейчас готовую реализацию -Ну если вы им либы перепишете - они может и схарчат.
> задолбаешься убеждать товарищей, коотрые сетевую прозрачность в гробу видели.
Я вот ее в гробу видел, если для ее реализации надо тормозной и неэффективный протокол, тормозящий локальную работу графики и дико жрущий бандвиз сети. Таким гэ я все-равно не пользовался и не собираюсь, ибо оно в такой инкарнации имеет очень нишевое применение. А мне проще xrdp или vnc заюзать, оно по крайней мере даже через 3G свисток сносно работать сможет без особых изгалений.
Я не имею ничего против сетевой прозрачности. При условии что это не в ущерб всему остальному. А вот это уже не про иксы и их протокол.
> Я вот ее в гробу видел, если для ее реализации надо тормозной
> и неэффективный протокол, тормозящий локальную работу графики и дико жрущий бандвиз
> сети.Есть прекрасная статья - http://habrahabr.ru/post/148954/ . Посмотрите на описание расширения XRender и соответствующую картинку:
"Для поддержки отрисовки примитивов с антиалиасингом в протоколе X11 есть специальное расширение, XRender (базовые операции рисования протокола X11 не используют антиалиасинг). Кроме отрисовки примитивов с антиалиасингом, это расширение позволяет использовать градиенты, матричные трансформации и т.д. "
Ясен пень, что нужно было сделать другие примитивы, более высокоуровневые, тогда не пришлось бы столько трапеций гонять по сети. Это бы, кстати, снизило бы и жор CPU.
Поэтому воюйте не с Х и их протоколом, а с расширением XRender.
> Ясен пень, что нужно было сделать другие примитивы, более высокоуровневые, тогда не
> пришлось бы столько трапеций гонять по сети. Это бы, кстати, снизило бы и жор CPU.Ну да, если бы взять, все сломать и передизайнить с нуля - оно могло бы быть и не таким ужасна@#м в плане производительности и не так паршиво рендерить.
> Поэтому воюйте не с Х и их протоколом, а с расширением XRender.
А что, в иксах уже есть средства быстрого вывода хоть той же пачки битовых карт? Именно разных, т.е. допустим видео заэмбеднутое в некую программу. Не надо только всякие негарантированные расширения сватать. Это во первых не гарантировано а во вторых заставляет прикладной софт знать как-то сильно уж дофига о специфике графической системы, что defective by design и идет вразрез с идеей кроссплатформенности. Т.к. имплементация поддержки такой графической системы в софте превращается в батхерт и изучение кучи особенностей. Вместо того чтобы, пилять, просто плевать на экран битмапы с той скоростью которой надо и не греть себе мозг!
> Ну да, если бы взять, все сломать и передизайнить с нуля -
> оно могло бы быть и не таким ужасна@#м в плане производительности
> и не так паршиво рендерить.Не надо всё ломать. Надо убрать XRender, xft, добавить хороший рендер шрифтов в сервер.
> Не надо только всякие негарантированные расширения сватать.
Сейчас массово установлена ровно одна имплементация Х - xorg. Поэтому что туда запихнут и будет стандартом де-факто. :-)
> Не надо всё ломать. Надо убрать XRender, xft, добавить хороший рендер шрифтов в сервер.Хороший рендер кушает проц. Одно дело если немного тупит 1 апликуха, активно выводящая сотни текста (например, терминал с интенсивным выводом файла). И совсем другое - если в итоге затупит вообще вся графическая подсистема которая крепко озадачивается некоей апликухой которая запросила сотни кил отрендереных текстов (должен ли я объяснить что качественный рендер векторного фонта - весьма ресурсоемкая операция?).
>> Не надо только всякие негарантированные расширения сватать.
> Сейчас массово установлена ровно одна имплементация Х - xorg. Поэтому что туда
> запихнут и будет стандартом де-факто. :-)Есть только одна проблема - часть расширений уповает на поддержку в драйверах и прочая. И если 2D апликухи начинают гнать графику как текстуры opengl потому что так быстрее - это сигнал тог что 2D подсистема обоср@лась с выводом 2D графики с нормальной скоростью.
> Хороший рендер кушает проц. Одно дело если немного тупит 1 апликуха, активно
> выводящая сотни текста (например, терминал с интенсивным выводом файла).Хороший рендер должен быть асинхронным и многопоточным. :-)
> Есть только одна проблема - часть расширений уповает на поддержку в драйверах
> и прочая. И если 2D апликухи начинают гнать графику как текстуры
> opengl потому что так быстрее - это сигнал тог что 2D
> подсистема обоср@лась с выводом 2D графики с нормальной скоростью.Дык никто не спорит, что рисовалка Х уже невменяема. Вы же видели эту статью, когда невинный бублик, кодируемый 30-тью байтами делится на тысячи трапеций.
> Хороший рендер должен быть асинхронным и многопоточным. :-)Да, а еще встроить туда планировщик ресурсов, адресно тормозящий особо наглые программы. А потом со всей этой фигней мы попробуем взлететь. Правда при этом сервер начнет делать явно работу ОС. Может его вообще в ядро тогда внести? Планировщики ресурсов - это уже явно туда напрашивается :)
>> opengl потому что так быстрее - это сигнал тог что 2D
>> подсистема обоср@лась с выводом 2D графики с нормальной скоростью.
> Дык никто не спорит, что рисовалка Х уже невменяема. Вы же видели эту статью,
> когда невинный бублик, кодируемый 30-тью байтами делится на тысячи трапеций.Я видел. Правда найти программы которые бы рисовали этот бублик через именно xrender еще суметь надо. По поводу чего я не уверен что это самая злобная проблема иксов.
> Я видел. Правда найти программы которые бы рисовали этот бублик через именно
> xrender еще суметь надо.Любая программа с Gtk/Qt.
> Любая программа с Gtk/Qt.Не в любой программе "с Gtk/Qt" есть данный вид бубликов рендеримых с интенсивностью при которой это станет проблемой.
> Не в любой программе "с Gtk/Qt" есть данный вид бубликов рендеримых с
> интенсивностью при которой это станет проблемой.В зависимости от пропускной способности сети. :-)
> В зависимости от пропускной способности сети. :-)Не, я допускаю что такие программы бывают, но чтобы оно стало проблемой - программа должна все-таки оперировать такими элементами. И я как-то не думаю что они в каждой программе интенсивно используются.
> Не, я допускаю что такие программы бывают, но чтобы оно стало проблемой
> - программа должна все-таки оперировать такими элементами. И я как-то не
> думаю что они в каждой программе интенсивно используются.Берём модем, Х сессию через него и 2 программы - одна на Gtk, другая на Motif. Компоненты и у той, и у другой визуально - унылое серое говно. Но Motif'овская, из-за того, что её примитивы в Х сервере поддерживаются, работает удовлетворительно. А Gtk'шная тормозит в прорисовке.
А потом запускаем xrdp и видим, что Ваше "удовлетворительно" совсем не удовлетворительно.
Пожатый видео поток с экрана требует уже канал, чем X протокол. Зачем нужна такая сетевая прозрачность?
> А потом запускаем xrdp и видим, что Ваше "удовлетворительно" совсем не удовлетворительно.Это вы к чему? Удовлетворительно в данном случае - тормозит, но плохонько работает. А неудовлетворительно - тормозит так, что работать никак нельзя. Единственные критерии - скорость прорисовки с точки зрения терпения пользователя.
При чём тут RDP вообще непонятно.
> Пожатый видео поток с экрана требует уже канал, чем X протокол. Зачем
> нужна такая сетевая прозрачность?Вы бы посмотрели, что такое RDP. Этот протокол - это гоняние примитивов, как Х протокол, а не битмапов, как VNC. Просто в особо упёртых случаях типа анимации RDP позволяет вместо примитивов гонять битмапы, но обычно - примитивы. См. http://msdn.microsoft.com/en-us/library/cc239611%28prot...
Поэтому, кстати, умные люди и говорят, что RDP - это аналог Х Window System для Виндов.
> как Х протокол, а не битмапов, как VNC.У vnc IIRC дельта-компрессия опциональна и сделана абы как. А в RDP по вашей ссылке значится что для GDI - это расширение протокола. Какое-то довольно дополнительное.
> RDP - это аналог Х Window System для Виндов.
Это какая-то очень грубая аналогия. В таком случае трактор - аналог танка :)
> У vnc IIRC дельта-компрессия опциональна и сделана абы как. А в RDP
> по вашей ссылке значится что для GDI - это расширение протокола.
> Какое-то довольно дополнительное.Ага, примерно как расширения Х, они типа тоже дополнительны. :-)
> визуально - унылое сeрoе гoвно.Пардон, у меня gtk/qt программы выглядят весьма симпатично (мне) и даже одинаково. А то что motif УГ - так я поэтому и не юзаю ни одной программы на данном тулките. Сами пользуйтесь таким уродством как-нибудь. То-есть, нежелание смотреть на столь блевотный UI перевешивает все остальное настолько что я в принципе не буду работать с такими программами кроме случая когда на меня наставили пистолет и пообещали расстрелять.
>> визуально - унылое сeрoе гoвно.
> Пардон, у меня gtk/qt программы выглядят весьма симпатично (мне) и даже одинаково.Посмотрите на E16/E17/старые битмаповские темы Gtk1 - среди них много очень приятных, значительно веселее текущего серого унылья.
Насчет нормального вектора- полностью согласен. А в идеале - вообще набор стандартных виджетов, чтобы по сети команды отрисовки вообще не ходили для них - только для того, что в этот набор не укладывается. Для 90% софта стандартного набора хватает. Правда если для вектора есть готовые подходящие библиотеки - Cairo та же, то для тулкита.. Разве что в сторону E смотреть.
> - только для того, что в этот набор не укладывается.И вот тут то и начинаются разные интересные грабли.
Никаких граблей. Для них летят просто команды отрисовки и ловятся элементарные события ввода, как сейчас происходит со ВСЕМИ контролами.
> Никаких граблей.Ну вообще может быть я и погорячился. А как например сие темить чтобы не выглядело совсем иначе чем остальная система? Контролы выглядящие как бельмо на глазу мало кому по вкусу.
Ну так мы ж знаем, какие элементы входят в тему (либо этожестко задано, либо можно запросить), их, понятно, надо будет получить с x-сервера (правда обычно нужны будут не сами элементы, а хэндлы их). И из этих же кирпичей конструировать виджет. Не сложнее и не проще, чем нестандартный виджет с подержкой темы сделать чисто на клиенте - то же самое - получаем информацию о теме и из нужных кусков конструируем.
> А в идеале - вообще набор стандартных виджетов, чтобы по сети команды отрисовки вообще не ходили для нихHTML5?!
:-)
Вы попытайтесь сделать там сколько-нибудь сложный интерфейс - сами всё поймёте. HTML5 для этого вообще непригоден, у него "поток" не даёт сделать всё удобно. Ну и набор виджетов в нём предельно примитивен. А руками TreeView какой-нибудь на джаваскрипте писать - занятие на редкость дурное.
>> А в идеале - вообще набор стандартных виджетов, чтобы по сети команды отрисовки вообще не ходили для них
> HTML5?!Ты зайди по-приколу на Plarium.com. Приколись, что у конторки в 50 рыл оборот больше, чем у всего РедХата вместе взятого - и подумай, погибнет ли Flash в обозримом будущем, ога?
> погибнет ли Flash в обозримом будущем, ога?Погибнет. Адоб его прибьет. Тренды не в его пользу, а адобе все-равно для чего именно средства ауторинга продавать. Да, ряд "кульных конторок" будет ждать забавный факап. Но это не проблемы адобы и браузероклепателей. Это будут проблемы тех 50 индивидов.
>> погибнет ли Flash в обозримом будущем, ога?
> Погибнет. Адоб его прибьет. Тренды не в его пользу, а адобе все-равно
> для чего именно средства ауторинга продавать. Да, ряд "кульных конторок" будет
> ждать забавный факап. Но это не проблемы адобы и браузероклепателей. Это
> будут проблемы тех 50 индивидов.Не-а. В мире бизнеса вменяемые челы не рубят курицу, несущую золотые яйца. ROI не позволяет, ну и многие другие умные слова. Это в мире СПО можно в одну ночь все с ног на голову поставить - а чо, ЛПР вошедшего баблом же нету, отвечать фактически не перед кем.
а исходники версии, где «не поставили», религия запрещает взять, конечно. ведь тебе должны принести на блюдечке, с поклоном. ты же Соизволил Обратить Внимание.
Всё, Балмер, допрыгался )
У Балмера уже давно убунту на домашнем компе. Он как и ты ждет вейланд.
Можно я скажу, почему client-side рендеринг и VNC-подобный протокол с передачей готовых битмапов - не такой уж плохой вариант? Потому что современным GUI-тулкиты один фиг отрисовывают всё в виде готовых битмапов и уже их отдают X-серверу. А делают они так по той причине, что старые-добрые команды для рисования геометрических примитивов, которые так хороши для сетевой прозрачности, не отвечают сегодняшним требованиям. Потому что никто не хочет сидеть в 80-х с motif-like виджетами и зазубренными шревтами, а все хотят нелинейные градиенты, сглаживание, всякие тени и блур, даже в веб-страницах - право, дешевле сразу рисовать это в битмап. Qt давно уже по умолчанию использует graphycssystem raster, например. Ну и вообще, потребности у людей всё время растут, и для каждой фигни реализовать server-side рендеринг ну нереально же. Ну и плюс пропускная способность сетей растёт, через момед уже давно никто не сидит, так что перегонка сжатых битмапов перестаёт быть проблемой. А к тому моменту, когда Wayland наконец станет готов для десктопа (годика через три), так и вовсе окажется, что олдскульная X11-style сетевая прозрачность уже и вовсе не актуальна. Примерно как в своё время все возмущались, что в новые компьютеры не ставят 5.25" дисководы, ну и где они теперь, лол?
> А делают они так по той причине, что старые-добрые
> команды для рисования геометрических примитивов, которые так хороши для сетевой прозрачности, не отвечают сегодняшним требованиям.А дополнить старые-добрые команды для рисования геометрических примитивов новыми-злыми совсем нельзя? :-)
VNC никогда не встроит удалённую программу в десктоп, как родную. Она будет выглядеть неудобно и чужеродно.
Так X12 же. Они там у себя примерно к тому же выводу пришли: чем пытаться изобретать новые команды, да так, чтоб их хватило хотя бы на будущие 10 лет... лучше уж битмапы.> VNC никогда не встроит удалённую программу в десктоп, как родную. Она будет выглядеть неудобно и чужеродно.
Пустое. Просто тупой VNC передаёт всю картинку десктопа целиком, а можно передавать каждое окно в отдельности, тогда разницы с традиционными иксами и не заметишь.
> Так X12 же. Они там у себя примерно к тому же выводу пришли: чем пытаться изобретать новые команды, да так, чтоб их хватило хотя бы на будущие 10 лет... лучше уж битмапы.Слабовата команда Xorg. :-( А Mitовцы что-то новые Х пилить не собираются.
> Пустое. Просто тупой VNC передаёт всю картинку десктопа целиком, а можно передавать каждое окно в отдельности, тогда разницы с традиционными иксами и не заметишь.
Заметишь. Для начала, там не те шрифты, не тот dpi, что на дисплее.
Шрифты в любом случае в последние лет 10 рендерятся на стороне клиента. А использовать правильный DPI архитектура Wayland никак не запрещает. Будут только очевидные проблемы при подключении к существующей сессии с другого устройства, но эта проблеома и в иксах никак не решена.
> Шрифты в любом случае в последние лет 10 рендерятся на стороне клиента.Ну это черезжопный способ, от которого нужно уходить.
> А использовать правильный DPI архитектура Wayland никак не запрещает.
Она, увы, слишком много разрешает.
> Будут только очевидные проблемы при подключении к существующей сессии
> с другого устройства, но эта проблеома и в иксах никак не решена.А стоило бы решить. :-)
>Ну это черезжопный способ, от которого нужно уходить.А вот меня сестра учится на факультете китаистики и подрабатывает рисованием визиток и вывесок. Расскажи ей, как хорошо будет от рендеринга шрифтов с вэньянем (древнекитайский, иероглифов раз в 5 больше чем в современном и пишутся они как на Тайване, а не как в Китае) на стороне сервера. Понятно, что таких как она 1%, ну так и сетевая прозрачность например тоже нужна 1%.
>Она, увы, слишком много разрешает.
А не надо ничего запрещать, надо предоставить приложению полную информацию об устройстве вывода (глубину цвета, dpi) и пусть они учитываются в его контексте рендеринга. От самого приложения это ничего не потребует, работать в любом случае будет фреймворк.
> вэньянем (древнекитайский, иероглифов раз в 5 больше чем в современном и
> пишутся они как на Тайване, а не как в Китае) на стороне сервера.Всем остальным тоже будет хорошо когда какой-нибудь терминал начнет рендерить в три горла вывод какой-иить очень вербозной программы и рендерер начнет жрать больше самой программы, при том самым логичным действом ака ренайсом программы это не лечится :)
Это лечится банальным сворачиванием окна программы - не рендерить то, что не показываешь - здесь rocket science не нужен.
> А вот меня сестра учится на факультете китаистики и подрабатывает рисованием визиток
> и вывесок. Расскажи ей, как хорошо будет от рендеринга шрифтов с
> вэньянем (древнекитайский, иероглифов раз в 5 больше чем в современном и
> пишутся они как на Тайване, а не как в Китае) на
> стороне сервера.Лучше ты расскажи, что плохо-то будет?
>>Она, увы, слишком много разрешает.
> А не надо ничего запрещать, надо предоставить приложению полную информацию об устройстве
> вывода (глубину цвета, dpi) и пусть они учитываются в его контексте
> рендеринга. От самого приложения это ничего не потребует, работать в любом
> случае будет фреймворк.И шрифты с устройства рендеринга нужно дать, палитру, dpi, цветовую гамму кнопочек. :-) Не проще ли на сервере рисовать?
>И шрифты с устройства рендеринга нужно дать, палитру, dpi, цветовую гамму кнопочек.Наоборот, не нужно.
От устройства рендеринга в вяленой архитектуре вообще ничего кроме dpi и палитры не нужно, да и те опциональны. Его приложение Х дергает сообщениями типа "я нарисовал битмап, выведи его на экран". Что оно там нарендерило, вяленого не волнует.
Он берет битмап, обзывает его окном приложения Х и выводит, если юзер щелкает по нему мышкой то шлет обратно сообщение где щелкнул. Если при рендеринге были учтены палитра и dpi, вяленый выведет красиво, если не учтены, выведет некрасиво. Но в любом случае выведет.
Проблема заголовков окон тоже надуманная. Вам не пох@й, кто их рисует - графический сервер или программа сама себе?
> Он берет битмап, обзывает его окном приложения Х и выводит, если юзер
> щелкает по нему мышкой то шлет обратно сообщение где щелкнул. Если
> при рендеринге были учтены палитра и dpi, вяленый выведет красиво, если
> не учтены, выведет некрасиво. Но в любом случае выведет.А почему он будет выводить менюшки и кнопочки программ не теми шрифтами, что у меня подобраны, а теми, что на удалённой машине?
> Проблема заголовков окон тоже надуманная. Вам не пох@й, кто их рисует -
> графический сервер или программа сама себе?Нет, конечно. Потому, что я уже видел зоопарк заголовков на десктопе с 4-мя (четырьмя) окнами.
>А почему он будет выводить менюшки и кнопочки программ не теми шрифтами, что у меня подобраны, а теми, что на удалённой машине?Вяленый вообще про шрифты ничего не знает, что *твоя* машина *твоими* подобранными тобой шрифтами выведет, то он и покажет.
>Нет, конечно. Потому, что я уже видел зоопарк заголовков на десктопе с 4-мя (четырьмя) окнами.
Это точно проблема не вяленого. Если программист долбо@б, его творение и в Х все переопределит.
> Вяленый вообще про шрифты ничего не знает, что *твоя* машина *твоими* подобранными тобой шрифтами выведет, то он и покажет.Если он ничего не знает про шрифты, то он не расскажет удалённой программе, какие же шрифты на терминале. Значит, она в любом случае выдаст результат "от балды". Даже если программист не "долбоёб" (ты почему-то стыдишься это слово написать).
> стыдишься это слово написать).На опеннете есть вордфильтр, так что если написать "долбоeб" от анонимуса - опеннет начнет врать что отсылка сообщений в ветку доступна только для зареганых пользователей. Это вранье, на самом деле привилегия ругаться доступна только для зареганных пользователей :). При том руганью считаются и безобидные словечки типа "не нужно" (во маразм) или "кoпать". Ну в общем те кто делал вордфильтр - очень странные люди с очень странной реализацией "фичи". Стесняются назвать цензорера цензорером и вносят в него левак, никак не индицируя какое именно слово вызывает нарекания. Руки обрывать за такую реализацию багофич!
> На опеннете есть вордфильтр, так что если написать "долбоeб" от анонимуса -
> опеннет начнет врать что отсылка сообщений в ветку доступна только для
> зареганых пользователей. Это вранье, на самом деле привилегия ругаться доступна только
> для зареганных пользователей :).Боже, какая ужасная несправедливость! Спасибо за разъяснения, надо попробовать ругнуться из-под анонима.
------------------------
Дополнение - проверил, прекрасно ругается, никакого фильтра не обнаружено. Причём ругаться можно как с буквой "ё" (для эстетов), так и с буквой "е".
>> На опеннете есть вордфильтр, так что если написать "долбоeб" от анонимуса -
>> опеннет начнет врать что отсылка сообщений в ветку доступна только для
>> зареганых пользователей. Это вранье, на самом деле привилегия ругаться доступна только
>> для зареганных пользователей :).
> Боже, какая ужасная несправедливость! Спасибо за разъяснения, надо попробовать ругнуться
> из-под анонима.
> ------------------------
> Дополнение - проверил, прекрасно ругается, никакого фильтра не обнаружено. Причём ругаться
> можно как с буквой "ё" (для эстетов), так и с буквой
> "е".Ты б внимательней смотрел, что тебе пишут, потом отвечал. Тот анон русским языком написал "для зареганых".
> Слабовата команда Xorg. :-( А Mitовцы что-то новые Х пилить не собираются.Она нормальная. Просто как обычно победили инженеры которые делают чтобы работало и желательно так как надо юзерам а не академики которые делают чтобы было красиво но бесполезно для большинства окружающих. По тем же причинам монолиты зарулили микроядра почти везде, а бсдшники проиграли линуксоидам, etc.
> Она нормальная. Просто как обычно победили инженеры которые делают чтобы работалоЧто же у этих инженегров Хorg загибается-то? ;-)
Открою небольшой секрет, Х проектировали тоже инженеры. Инженеры из DEC - ведущей тогда компьютерной конторы, на много лет задавшей вектор развития систем.
>...и для каждой фигни реализовать server-side рендеринг ну нереально
> же. Ну и плюс пропускная способность сетей растёт...OpenGL, например, изначально проектировался для рендеринга по сети. И каждая новая фишка, реализованная в железе, но не реализованная в софте так или иначе создаёт проблему. А растущая пропускная способность сети, не повод не использовать её эффективно. Это сейчас 1920х1080 норма, а "завтра" 2600х1400 или ещё больше. И что, молиться на технологии пожатия картинок?. И Вы забываете про анимацию. Различные эффекты... И вот у Вас уже видеопоток... А в тот же Compiz легко засунуть логику предачи информации как трансформировать объект "там", на удалённой стороне. В конце коцов, RDP и иже с ними тоже совершенствует методику передачи метаданных вместо совершенствования методик пожатия картинок (там уже выжали максимум) и в этом плане RDP всё более становится похож на X протокол
> OpenGL, например, изначально проектировался для рендеринга по сети.Осталось только найти тех кто это реализовал и этим пользуется...
> и в этом плане RDP всё более становится похож на X протокол
Вот только IIRC там нельзя переслать отдельно взятое окно как в иксах. По поводу чего оно похоже не более чем трактор на танк.
> Пустое. Просто тупой VNC передаёт всю картинку десктопа целиком, а можно передавать каждое окно в отдельности, тогда разницы с традиционными иксами и не заметишь.Заметишь. Для начала, шрифты не те, dpi не то.
USE="-X wayland" #не за горами?
Ну, это у кого как. У меня будет ровно обратное как минимум ближайшие года 4 - есть шанс, что основные грабли за это время уберут.
> Ну, это у кого как. У меня будет ровно обратное как минимум
> ближайшие года 4 - есть шанс, что основные грабли за это
> время уберут.Я бы надеялся на то, что не уберут. Ибо зачем менять шило на мыло?
т.е. фишечки в виде бесшовной загрузки/работы/переключения консолей/выключения в части графической подсистемы по-вашему не нужны?Не за горами qt-5/kde5 работающая на wayland. Было бы интересно взглянуть.
> т.е. фишечки в виде бесшовной загрузки/работы/переключения консолей/выключения в части
> графической подсистемы по-вашему не нужны?Не такой ценой. В конце-концов, я же не смотрю на машину, когда она грузится. А в консолях не работаю - xterm + i3 также удобны, а шрифты у них лучше.
> Я бы надеялся на то, что не уберут. Ибо зачем менять шило на мыло?Может хватит этой пенсионерской брюзжатины ? постоянно путаете графическую подсистему с оконным менеджером, прославляете протухший Unix и мертвые конторы с вектором из прошлого тысячелетия, уродский motif c какой-то нелепой сетевой прозрачностью на модемах - смешно читать.
> Может хватит этой пенсионерской брюзжатины ? ... смешно читать.Дорогой друг, вас тут никто не задерживает. И читать мои реплики не заставляет. Или "Ватсон без трубки уже не мог"? :-)
> Дорогой друг, вас тут никто не задерживает.таких как вы друзей, извините - за х.й да в музей :-)
> таких как вы друзей, извините - за х.й да в музей :-)То есть, я правильно насчёт трубки предположил? :-) Ну смотрите, только конец не перепутайте!
Vkni, твой КАЖДЫЙ пост с плюсиком. Сам себе расставляешь?
> Vkni, твой КАЖДЫЙ пост с плюсиком. Сам себе расставляешь?Нет, я тут писал, что в каждом W сраче есть две стороны - антивейлендщиков (я в ней) и провейлендщиков. Так вот чаще всего вторые автоматом расставляют мне минусы по всем постам, а первые - плюсы.
Зачастую бывает так - в понедельник все мои посты с -1, а во вторник они уже с +1. Очень смешно. :-)
В этот раз провейлендщики спят, что-ли.
> Vkni, твой КАЖДЫЙ пост с плюсиком. Сам себе расставляешь?Тут вообще с плюсами странно - у тебя был один плюс, я тебе поставил ещё один. А сейчас у тебя почему-то лишь +1, а не +2.
>> Vkni, твой КАЖДЫЙ пост с плюсиком. Сам себе расставляешь?
> Тут вообще с плюсами странно - у тебя был один плюс, я
> тебе поставил ещё один. А сейчас у тебя почему-то лишь +1,
> а не +2.А ты думаешь, тут ты один только плюсуешь-минусуешь? Ваш К.О.
И давно вас в музей определили?
> Может хватит этой пенсионерской брюзжатины ? постоянно путаете графическую подсистему
> с оконным менеджером, прославляете протухший Unix и мертвые конторы с вектором
> из прошлого тысячелетия, уродский motif c какой-то нелепой сетевой прозрачностью на
> модемах - смешно читать.Вот и меня это в данном гражданине несколько утомляет. Я не собираюсь пользоваться у...щем типа motiff. И древние юниксы сыграли в ящик не просто так. А сетевая прозрачность для меня лишь весьма опциональная плюшка, т.к. я не развлекаюсь запуском математики на ремотном сервере. И квейк я предпочитаю локально запускать. При том третий и на нормальном разрешении экрана. Которое задолбается по сети пропихиваться, если просто бандвиз картинки посчитать.
Честно говоря, есть подозрение, что рано или поздно на этот вейланд таки всех спихнут. Чем позже - тем лучше, конечно.
> Честно говоря, есть подозрение, что рано или поздно на этот вейланд таки
> всех спихнут. Чем позже - тем лучше, конечно.Сомнительно, всё же. Очень большой слом совместимости + недостатки. Я вообще сомневаюсь, что он будет менее ресурсожрущий чем Х.
В общем, я оптимист, а вы - пессимист. :-)
weston уже менее ресурсожрущий, а над оптимизацией там не шибко заморачивались
> weston уже менее ресурсожрущий, а над оптимизацией там не шибко заморачивалисьОно же ещё не доделано. Надо смотреть в результате - система с KDE/X и система с KDE/W. KDE - потому, что эта DE наиболее самодостаточна.
Вообще https://sourceforge.net/projects/rebeccablackos/
Хотя да не доделано. Вообще ситуация как с FS, каждая fs имеет сильные и слабые стороны.
> KDE/X и система с KDE/W.Я вот XFCE пользую. Потому что не надо мне самодостаточных мускул-серверов в десктопной системе.
что он меньше жрёт и где?
Жрет меньше ресурсов в Linux
см. выше. пока ровно строго наоборот. и непизвестно будет ли лучше.
Linux-only. Не нужно.
Посмотри сколько жрут иксы ресурсов при перемещении окна, а потом сравни это с mac os.
> Посмотри сколько жрут иксы ресурсов при перемещении окна, а потом сравни это
> с mac os.Хоть сравни хоть нет. Вруби софтовый эмулятор хуч в той же венде и подергай окошко мышом. Потом вруби аксель и снова сравни. И то же самое ровно в любой системе.
При чем здесь софт вообще?
Нуту в системе софтового эмулятора хуч ))
Есть софтварный рендиренг. Вы мне предлагаете посмотреть а работу софтварного рендирегна в системах и сказать что с hw акселирацией лучше. Спасибо я и так это знаю.
Действительно окошко рендирит себя в вакуме без всяких прослоек не тратя ресурсы.
> Хоть сравни хоть нет. Вруби софтовый эмулятор хучНе знаю что такое "софтовый эмулятор хуч", но мыша в винде натурально стало клинить в последних версиях. А раньше плавно каталось. Даже странно что индусы смогли это сломать.
>> Хоть сравни хоть нет. Вруби софтовый эмулятор хуч
> Не знаю что такое "софтовый эмулятор хуч", но мыша в винде натурально
> стало клинить в последних версиях. А раньше плавно каталось. Даже странно
> что индусы смогли это сломать.(флегматично) Ты с родным языком, боюсь, незнаком. "Хуч" = "хоть", такое намеренное посконное искажение, тонкий троллинг.
> Linux-only. Не нужно.Иксы, месу и драйвера вокруг них нынче тоже под линукс в основнои пиляют. Требуя ряд ядерных интерфейсов которые остальные реализовать не удосужились толком. Никто не собирается равняться на трупиков и слоупоков. Ибо задолбало.
Непонятно,почему выкинув сеть вобще не разделится на локальную графическую систему и работающий поверх неё X сервер.
Каждый займётся своей нишей.
Графическая система будет делать FPS в казуалках для домохозяек,а Х сервер удалёнными приложениями.
Кстати,надеюсь что никто не будет спорить о том,
что пользоватся вэб интерфейсом банка(вобще работать) и "лазить по порносайтам" лучше с разных машин и Хсы для этого весма бы пригодились,
ибо собрать всё это на одном мониторе на третьем компьютере былобы удобно.
Да и мощную видеокарту можно тогда покупать только одну.
Быть может развал Хсов это тайные козни AMD и Nvidia?)
К стати в Х ещё можно сделать работу с клиентом конектищимся сразу с подсети,
что очень понравится манфреймщикам и игроманам,так как кластер из четырёх восмиядерников победит любую видеокарту,при том,что просче в программирований,
эксплуатаций(Меньщие охлаждение и мощьность БП) и универсальнее.
Это ещё один аргумент в пользу моего предположения о кознях корпораций.
> Непонятно,почему выкинув сеть вобще не разделится на локальную графическую систему и работающий
> поверх неё X сервер.
> Каждый займётся своей нишей.
> Графическая система будет делать FPS в казуалках для домохозяек,а Х сервер удалёнными
> приложениями.
> Кстати,надеюсь что никто не будет спорить о том,
> что пользоватся вэб интерфейсом банка(вобще работать) и "лазить по порносайтам" лучше сВобще, вобще.
> разных машин и Хсы для этого весма бы пригодились,
Весма, весма.
> ибо собрать всё это на одном мониторе на третьем компьютере былобы удобно.
> Да и мощную видеокарту можно тогда покупать только одну.А здесь чо мягкий знак пропустил-то? Мощьную, чего уж там мелочиться-то!
> Быть может развал Хсов это тайные козни AMD и Nvidia?)
> К стати в Х ещё можно сделать работу с клиентом конектищимся сразуКонектищимся, конектищимся.
> с подсети,
> что очень понравится манфреймщикам и игроманам,так как кластер из четырёх восмиядерников
> победит любую видеокарту,при том,что просче в программирований,Просче, просче, ага. Кстати, твое утверждение ничего не стоит. Не лез бы ты в то, в чем ни уха ни рыла не сечешь, ага?
> эксплуатаций(Меньщие охлаждение и мощьность БП) и универсальнее.
Меньщие, меньщие, мощьность, мощьность.
> Это ещё один аргумент в пользу моего предположения о кознях корпораций.
А у меня предположение, что ты школоло неграмотное. Каникулы начались? И Розенталь в гробу вертится, аки пропеллер?
