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