>> даже может думать в терминах битмапов.
> Это всё-таки исключения. Не согласен. Реалии современного мира таковы что большинство программ будут рады до поросячьего визга тупому но быстрому фреймбуферу + 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 - это разжиревшие монстры, делающие всё, но крайне фигово.
Ну не все. А лишь то чего хотели пользователи. Спрос рождает предложение.
