[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: xorg: Fatal server error: could not open default font 'fixed'



On 2006.10.04 at 15:58:48 +0400, Max Dmitrichenko wrote:

> 
> Вопрос в том, где и на какой стадии информация о глифе теряется и он превращается
> в кучу пикселей. Если на стороне клиента (когда он рендерит сам), то по
> X-протоколу летит растровое изображение, если на стороне сервера - то
> информация о шрифте и печатаемый текст.
> В втором случае о глифах знает только X-сервер и ничего лишнего по сети не
> летает.

В первом случае тоже принимаются меры, чтобы по сети ничего лишнего не
летало. Один раз посылается "кучка пикселов" (bitmap или pixmap) а потом
гоняется только её хэндл. В случае server-side рендеринга, X-сервер тоже
должен с фонт-сервера получить кучу пикселов. Только идентифицироваться
она будет не хэндлом кэшированного pixmap, а XLFD-именем шрифта и
кодовой позицией в оной. 


На этом основании Паккард сделал вывод, что клиент-сайд рендеринг не
хуже, чем сервер-сайд. URL на статью, где подробно описываются
результаты тестирования оной конструкции тут Гусаров недавно постил.

Беда в том, что типичный паттерн использования X-ов предполагает, что на
одном X-сервере запущено несколько десятков программ, возможно, с
разных машин. В случае server-side  рендеринга шрифта все эти программы
при запросе одного и того же символа из одного и того же шрифта получат
один и тот же pixmap. Потому что закэшированный в сервере pixmap
идентифицируется одинаково для любой программы.

В случае клиент-сайд рендеринга программа A не знает и не может узнать,
что программа B уже отрендерила и закэшировала на сервере нужный ей
символ. Поэтому будет рендерить и кэшировать заново.

В результате получается что X-серверу потребуются десятки мегабайт
памяти на кэш. А по старой схеме у меня терминал NCD ESX прекрасно живет
с 4 Мб на всё про всё, включая код X-сервера и ядра операционной
системы, встроенный window manager, консоль управления и т.д.




Reply to: