Re: Минимальная система
Victor Wagner <vitus@wagner.pp.ru> writes:
> Это хорошо если у тебя на экране ровно одно приложение. Если у тебя
> там десяток разных приложений, использующих один и тот же шрифт (что
> крайне осмыслено для создания единого стиля десктопа), то каждое
> приложение будет рендерить буковки заново, даже если эти приложения
> работают на одном хосте (а если на разных, то средствами библиотек
> рендеринга это вообще не лечится). А в случае server-side xserver
> возьмет одну и ту же отрендеренную букоску из кэша.
Сейчас не возьмусь проверять, но, может быть, меня поправят, если что,
но X-сервер все-таки кэширует отрендеренные картинки даже в случае
client-side rendering. Что-то где-то я читал, что они в виде хэша
сохраняются на стороне X-сервера. А кэш и reusing глифов на стороне
клиента на уровне Xft -- это уже давно данность.
> А антиалиасинг is evil
Это вопрос религиозный, наверное, уже. И правды мы не найдем. В любом
случае, X core fonts и прежний метод отрисовки никто не убрал и убирать
не собирается, пока есть куча ПО на lesstif, xaw, Tk и пр. И ПО это до
сих пор создается даже, но не так масштабно, как ранее.
> Вообще говоря, жалко что это не реализовалось. Наличие альтернативных
> реализаций xlib сильно способствовало бы повышению качества софта.
Альтернативные реализации библиотеки над X-протоколом до сих пор
возможны. Такие были для Java (XTC, Escher), SmallTalk (STIX), ML
(eXene), Common Lisp (CLX). Но они не получили развития. Хотя CLX я
использую. Повторю мысль о том, что старый метод отрисовки шрифтов не
умер. Он просто без внимания. Использовать никто не
запрещает. client-side rendering тут, конечно, существенно осложняет
ситуацию для других языков, так как написать библиотеку для рендеринга
шрифтов на том же Common Lisp возьмутся только отважные психи. Поэтому в
угоду новым веяниям все-равно приходится биндится к Xft или использовать
server-side rendering по старинке. Хотя, соглашусь, красота решения
пропадает. Это как ложка дегтя в бочке с медом: раз уж забиндился один
раз к Xft (Си), то зачем же ты уперто остальное делаешь без
биндингов. :)
>> сегодня. Все биндятся к xlib или более высокоуровневым тулкитам, и
>> работают.
>
> И практически никакой конкуренции между тулкитами.
Между тулкитами не может быть конкуренции. Между ними может быть только
религиозная война. :)
А вот XCB как раз и дает возможность независимости от xlib и некоторого
соревнования. XCB -- это самое простое, что можно придумать: обертка на
Си над каждой командой X-протокола плюс модуль XCB Connection для
установления и разъединения соединения с X-сервером. Библиотека имеет
минимальный размер. Все оптимизации и группировки запросов, которые были
раньше в xlib и многое другое просто выкинуты и отданы на откуп
пользователю XCB. То есть при использовании XCB каждый тулкит теперь сам
волен решать, как ему оптимизировать запросы, как группировать, что
кэшировать. При xlib контроля над этим не было, а теперь вот так
предлагается. Помимо этого, XCB предоставляет свои функции для упрощения
написания программ для X, ноони имеют у них статус "utility", т. е. их
использовать не обязательно. Но еще, насколько я понимаю, ничего не
портировано на XCB или это имеет экспериментальный статус.
А чтобы реализовать асинхронность, в XCB введено понятие cookie. То есть
посылая запрос X-серверу, XCB не ждет ответа, а просто резервирует
cookie, куда этот ответ потом запишется, когда придет, а сама, программа
идет дальше. Таким образом, запросы, на которые долго ответ идет не так
значительно фризят дальнейшую работу.
Reply to: