"Nikita V. Youshchenko" <[EMAIL PROTECTED]> writes:
> Дело в том, что X протокол - это далеко не только рисование и получение > ввода. Это ещё и Atoms, Properties и т.п. Это так. В диалоге опущено важное словосочетание "в среднем уменьшает влияние latencies", а не совсем исключает. А есть информация, насколько именно эти "диалоговые" запросы влияют на общую работу? Каков процент времени их в общей картине? А на "монологовые" операции, насколько я понимаю, xlib все-равно ждет ответы. На каждую. > А решение этой проблемы - архитектура с X proxy. Когда роль X сервера играет > X proxy, работающий на сервере приложений. > А для доступа к удалённым устройствам X proxy использует не X протокол, а > что-то более приспособленное к работе на медленной сети. Да так всегда и решали. X proxy -- это один из компонентов всего решения для медленных сетей. Но все-таки возможность оптимизации, начинающейся уже от приложения -- это тоже хороший шаг. XCB, кстати, в ветке был приведен совсем не как замена прокси-уровню, а (если вернуться в самое начало, где XCB упоминается), как шаг в сторону обозначения и начала частичного решения проблем c X-протоколом и xlib. О некоторых проблемах xlib, которые увидели авторы XCB, говорится в [1]. XCB не нацелен на решение исключительно проблем медленных каналов, а как решение, несколько изменяющее подход к написанию X-клиентов, которое в некоторых направлениях должно дать улучшения (по мнению авторов). [1] http://www.freedesktop.org/software/xcb/xfree86-xcb.pdf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
