> Не согласен. Реалии современного мира таковы что большинство программ будут рады до
> поросячьего визга тупому но быстрому фреймбуферу + 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.