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, консоль управления и т.д. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
