Evgeny M. Zubok wrote: > Michael Shigorin <[EMAIL PROTECTED]> writes: > >> Насколько понял XCB whitepaper, с roundtrip times тоже не супер. > > А я что-то не читал такой whitepaper. Хорошо, а какое решение мыслится > еще, кроме XCB? Что еще можно придумать, кроме передачи группы запросов > X-серверу на отрисовку чего-либо с отсроченным получением ответов?
Дело в том, что X протокол - это далеко не только рисование и получение ввода. Это ещё и Atoms, Properties и т.п. Причём и рисование, и получение ввода - операции по природе своей "монологовые". Для рисования нужно только передавать, "что рисовать", и не нужно никаких ответов. Следовательно, буферизация возможно сколь угодно большая. Для ввода то же самое - передавать надо только события, буферизируй сколько угодно. А вот другая часть X протокола - не связанная непосредственно с обменом с устройствами - как раз диалоговая. До получения ответа на запросы XInternAtom или XQueryProperty программа не может продолжаться. И ей приходится ждать, пока ответ придёт по сети. Хотя вообще говоря для получения этого ответа доступ по удалённых устройств не нужен. Из-за этого можно утверждать, что X протокол плохо приспособлен к работе на медленной сети. А решение этой проблемы - архитектура с X proxy. Когда роль X сервера играет X proxy, работающий на сервере приложений. А для доступа к удалённым устройствам X proxy использует не X протокол, а что-то более приспособленное к работе на медленной сети. Две наиболее известные реализации этой идеи - VNC и NX. В обоих случаях налицо и X proxy, работающий на стороне сервера приложений, и протокол, оптимизированный под работу с удалёнными устройствами. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
