Victor Wagner <[EMAIL PROTECTED]> 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. Такие вот мысли. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
