Re: Минимальная система
Victor Wagner <vitus@wagner.pp.ru> writes:
> Его использование в этих монстрах. В первую очередь - client side
> rendering шрифтов. Конечно, X протокол тоже немножкно виноват -
> возможности работы со шрифтами там немножко отстают от требований
> современности.
Виктор, ничего в client side rendering плохого нет. Наоборот, этот
подход даже идеологически лучше, чем server side. Во-первых, не надо
никакого xfs и дурацкого второго канала. Во-вторых, теперь буковки наши
-- это и есть X-протокол + опционально Render Extension, если расширение
имеется на X-сервере. Если нет расширения, то глифы просто будут
монохромными без всяких там AA. Причину, по которой появились server
side rendering, я вижу в начальных технологических предпосылках к
появлению X-протокола: (i) каналы были более медленными; (ii) шрифтов
было ограниченное количество; (iii) если использовался xfs, то
ускорялась несколько отрисовочка, так как X-сервера в основном
однотредные, а отрисовочка проводилась сервером шрифтов в другом месте
параллельно; (iv) языконезависимость X-клиентов. Последний пункт о том,
что в самом начале предполагалось, что X-клиенты, написанные на разных
языках, будут общаться с X-сервером по X-протоколу напрямую. В то время
развитой инфраструктуры FFI для подключения библиотек на Си не было у
очень многих языковых реализаций. Поэтому отрисовку шрифтов удалили на
сервер, а клиент только простые паттерны (семейство, размер, наклон,
толщину и пр) засылал. Это упрощало написание X-клиентов на всякой
экзотике (по сегодняшним меркам). Например, на Common Lisp есть
библиотека CLX, которая работает с X-протоколом напрямую. И весьма
успешно. Но вот оказалось, что возможность эта особо и потребовалась
сегодня. Все биндятся к xlib или более высокоуровневым тулкитам, и
работают.
>
> Но авторы тулкитов Gtk и в меньшей степени Qt, похоже в принципе не
> понимают всех возможностей X-ов и писали свои тулкиты так, чтобы
> написать на них программы, работающие быстро по узкому каналу было
> принципиально невозможно.
Проблема именно в latency сети. Это наследственная болезнь X-протокола,
так как он синхронный. Проблему как бы решают. Во-первых, есть NX и его
свободная реинкарнация FreeNX. Попробуй тест-драйв с nomachine.com на
скорости 56k в GNOME-сессии или KDE-сессии, которая на итальянском
сервере где-то. Отпадут всякие сомнения в том, что это не проблема в Gtk
и KDE. Во-вторых, сейчас еще вот будут, наверное, внедрять XCB. По
замыслу (имеется бумага с USENIX 2001 на freedesktop.org) эта бибиотека
должна заменить xlib и она будет асинхронной, что позволит снизить
влияние latencies. Но там только сжатие графики нет и прочих
оптимизация. Насколько я понимаю, это должно быть вынесено на
прокси-уровень,к а кэто и сделано в NX.
Такие вот мысли.
Reply to: