Font Anti-Aliasing and Render Extension

Вообщем, Кейта Пакарда - в газенваген...
Хайль, Столлман!

Честно говоря, я тоже не понял, почему вместо доделывания x core font system прикрутили подозрительный костыль

Я тут еще статейку Пакарда нарыл, с объяснениями как он до этого докатился. Аргументация, мягко говоря, не впечатляет.
http://keithp.com/~keithp/talks/xtc2001/paper/

До чего же этот Пакард деятельный мудак:

underlying rendering mechanism...no longer depends on the capabilities of the X server. Integrating new font technologies can now move at the rapid speed of individual application development rather than the glacial speed of the general availabilty of new X server enhancements.

Т.е. весь источник конфликта XFree86<->X.org в одной этой фразе. XFree86 стояла за здоровый консерватизм, а Пакарду не терпелось понапихать всякой дряни в Х-протокол. На сервере ему резвиться особо не давали, так он переключился на клиентские библиотеки. Ну, а когда его деятельной натуре и этого показалось мало он устроил скандал в XFree и захватил X.org.

http://www.dcs.ed.ac.uk/home/jec/programs/xfsft/

>Ладно уж тесселятор сделан в клиенте, но чтобы клиент должен грузить глифы в Х-сервер ... Понятно теперь, почему все считают X-server тормозным. Еще бы - если прокачивать глиф для каждой буквы через сокет...

ну если бы ты следил за дискуссиями по этой теме чуть ранее, када кейт пакард тока-тока поднимал голову, то нашел бы и то, что оверхеда в варианте пихать глифы по сравнению с вариантом x core fonts/xfld - нету, проверяли.

зато у клиентского варианта (связка xft/freetype/fontconfig) есть туча плюсов, которые в варианте serverside fonts очень тяжело (в том числе и из-за костности и торможения xfree86 тусовки) сделать/пробить.

>Плохо, что эта кривизна вытесняет правильный Х-овый подход - X Core Font System. Например в последних версиях GTK откат с freetype невозможен :(

ну ты можешь использовать в pango пока еще x core fonts бакэнд, тока скорсти тебе это не прибавит. тормоза вовсе не в том, что гифы на сервер гоняют, тормоза в том, что xrender медлено растеризует. над чем люди усиленно и работают.

>>>оверхеда в варианте пихать глифы по сравнению с вариантом x core fonts/xfld - нету, проверяли.

А ссылки? Я регулярно использую Мозиллу удаленно, так разница со сглаженными/несглаженными шрифтами заметна невооруженным глазом.

>>>тормоза вовсе не в том, что гифы на сервер гоняют, тормоза в том, что xrender медлено растеризует. над чем люди усиленно и работают.

Те если ttf (typе1) шрифт не сглаженный -то растеризуется этот фонт быстро, а если сглаженный то медленно. Заметь, что растеризуемый контур при этом - один и тот же.

>>>можешь использовать в pango пока еще x core fonts бакэнд

В gtk2.8 его уже не получается задействовать. GDK_USE_XFT игнорируется.

http://www.usenix.org/events/usenix03/tech/freenix03/full_papers/packard/pack... - про мозилку в сети и вообще циферки и мысли про проблемы текущией (на 2003 год, но там пока ниче глобально не изменилось) реализации x-протокола, костыль lbx и ssh. плюс gecko не тривиальным образом работает со шрифтами.

>В gtk2.8 его уже не получается задействовать. GDK_USE_XFT игнорируется.

это проблемы использования pango (которое пока еще может x core fonts) в gtk. ;) вернее не проблемы, а руководящая и направляющая рука партии "если все будет красиво - сдерем многа денег с дурачков на gnome-десктопах" :(

>что оверхеда в варианте пихать глифы по сравнению с вариантом x core fonts/xfld - нету, проверяли.

Есть оверхед по памяти. самим файлам шрифтов проде программы делают mmap, но кеш отрендеренных глифов существует для каждого икс-клиента. Вместо одного кеша, который хранится в икс-сервере.

Есть также оверхед по инициализации системы fontconfig, которая делается каждым икс-клиентом.

Каждому икс-клиенту прилинковывается еще две библиотеки, это не ускоряет ни компиляцию ни запуск.

Такс. на счёт оверхеда по памяти - я малось поспешил:

As applications transmit images of each glyph they display, the X server conserves memory by sharing identical glyphs wherever possible. This eliminates duplicate glyphs both when sent by separate applications and even within each application..

ну за лишние две либы ты имеешь зато возможность не трогая серверную сторону подключать новые растеризаторы, работать с любыми существующими и возможными типами шрифтов и все что еще может душа пожелать, в принципе. по сравнению с тем, какие мучения и скока разных костылей прикручивали раньше к xfree для понимания хотя бы truetype/opentype - нормальная плата.

оверхед по иниту починили в районе 2.3.90.

Эту статью я читал. Но не понятно как вообще там был сконфигурирован X-server. К примеру никакие измерения не убедят меня, что при сетевой работе font-server, расположенный на X-servere, даст большую задержку, чем client-side шрифты, просто потому, что в первом случае шрифты отвязаны от сети совсем. Можете считать меня мракобесом и обскурантом. У Пакарда, скорее всего, был фонт-сервер расположенный на клиенте, поэтому он и получает сравнимые величины задержки.

Во-вторых - Пакард в статье рассматривает только старт мозиллы (configure event). На самом деле более интересен вопрос с отрисовкой окон, открывающихся после перекрытия (expose event). Как в этом случае ведет себя задержка? Вопрос не праздный, поскольку в server-side реализации шрифты уже находятся на x-server в виде ресурса и обращение к ним со стороны клиента требует толко пересылки одного идентификатора. А что с client-side? Заново персылать все глифы?

>>какие мучения и скока разных костылей прикручивали раньше к xfree для понимания хотя бы truetype/opentype - нормальная плата.

Выше была ссылка.

What are the alternatives?

Other than xfsft, there are at least two Free and a number of commercial servers handling TrueType fonts.

Xfstt can be found on TSFKA Sunsite in the directory Linux/X11/fonts. This was (as far as I know) the first Free TrueType rasteriser available, and is distributed under the Gnu Public License. It is written in C++, and has been entirely written by one person (Herbert Dьrr): the TrueType rasteriser, the transport layer, and the interface between the two. This is an amazing feat.

Xfstt компилируется за пять минут - ./configure, make, make install. При этом проект не заморожен, хотя и не быстро развивается (последнее обновление - ноябрь 2005). Хотя сглаживание в нем не реализовано, но назвать этот сервер "костылем" я не могу.

>>ну за лишние две либы ты имеешь зато возможность не трогая серверную сторону

Рассуждая таким образом, можно зайти очень далеко. Например, задаться вопросом - "А нахер он вообще нужен этот Х-сервер? Давайте его реализуем в виде клиентской библиотеки. А сетевую прозрачность сделаем через пересылку скриншотов по сети. Вот!"

>ну за лишние две либы ты имеешь зато возможность не трогая серверную сторону

Это, конечно, достоинство, но так можно далеко зайти. И так вывод ldd типичной гуишной программы всё удлинняется с каждым годом.

>А нахер он вообще нужен этот Х-сервер? Давайте его реализуем в виде клиентской библиотеки.

Разделять доступ многих клиентов к одной видеокарте. Иначе бы он давно в виде библиотеки был.

>А сетевую прозрачность сделаем через пересылку скриншотов по сети. Вот!

А в винде так и сделали, и почему-то очень быстро работает.

>>>А в винде так и сделали, и почему-то очень быстро работает.

"... а интернет придумал Билгейц". VNC-подходу сто лет в обед и появился он совсем не в M$.
Правда, когда дело доходит до бенчмарков, восторги быстро утихают...

>>>Разделять доступ многих клиентов к одной видеокарте. Иначе бы он давно в виде библиотеки был.

В принципе да, какой-то смысл в этом есть. Возможно у Пакарда действительно такая цель - двигаться к "тупому" серверу (который занимается только разделением доступа) за счет "умных" клиентов.

>Xfstt компилируется за пять минут - ./configure, make, make install. При этом проект не заморожен, хотя и не быстро развивается (последнее обновление - ноябрь 2005). Хотя сглаживание в нем не реализовано, но назвать этот сервер "костылем" я не могу.

ээ, ну ты вообще вкурсе, что начиная с xfree 4.x truetype шрифты нативно поддерживаются vanilla xfs и никакого xfstt не надо? и никто не мешает тебе задавать их в формате xfld? :) а вот раньше всякие xsftt, xfsft, x-truetype и редхатовский патченый xsf как раз и были костылями для xfree86. теперь их нет - все рады, ибо городить огород из 88 разных форматов конфигов - накуй не нада.

>Рассуждая таким образом, можно зайти очень далеко. Например, задаться вопросом - "А нахер он вообще нужен этот Х-сервер? Давайте его реализуем в виде клиентской библиотеки. А сетевую прозрачность сделаем через пересылку скриншотов по сети. Вот!"

ну если передергивать, то можно куда угодно зайти. :) сейчас имеем универсальную шрифтовую подсистему (freetype/fontconfig), не зависящяю ни от x, ни от приложений, ни от принтера - вроде бы нормальная мысль, не находишь? а то, что дольше рисуются локально - наследие дремучего xfree86, не более того.

>Заново персылать все глифы? один раз. там кеш есть ;) x core fonts тоже не идеальны - там дикий оверхед на опеарциях query/matching конкретного шрифта от приложения к серверу и обратно.

>"... а интернет придумал Билгейц". VNC-подходу сто лет в обед и появился он совсем не в M$.

А я обратного не утверждал. Но в винде такой подход довели до юзабельного состояния.

>Правда, когда дело доходит до бенчмарков, восторги быстро утихают...

Ну - когда я пробовал VNC, то rdesktop работал быстрее и надежнее.