Можно получить идеальные 60 FPS и зелёные метрики — и всё равно услышать от пользователей «невозможно работать». Потому что мозг прощает “мыло”, но не прощает задержку: курсор начинает жить своей жизнью, клики “не туда”, печать с запозданием.

В этой части разбираю Input Channel, Cursor Channel и round-trip latency: почему SPICE таскает курсор отдельным каналом, откуда берётся эффект «курсор на резинке», чем отличается server mouse mode от client mouse mode, и почему без usb-tablet / vdagent всё быстро превращается в квест.

Третья статья серии — про то, что реально определяет UX в VDI: не картинка, а отклик.

Парадокс: SPICE отлично справляется с рабочим столом, но спотыкается на видео. Статичный документ — чёткий, быстрый, экономный по трафику. Включили ролик на YouTube — и всё поплыло.

Display Channel — это два разных мира в одном канале. Image Mode: независимое сжатие каждой изменившейся области, умное кэширование, глобальный словарь для повторяющихся элементов интерфейса. Stream Mode: попытка поймать видеопоток и пережать его на лету.

Детекция видео по косвенным признакам. MJPEG из 2009 года как дефолт. GStreamer как путь к H.264. И вечный компромисс между «красиво» и «быстро».

Разбираю анатомию Display Channel — от QXL-команд до финального рендеринга. Вторая статья серии.

В 2007 году инженеры Qumranet приняли решение, которое определило судьбу протокола на следующие 17 лет: только TCP, никакого UDP. Простота победила производительность.

SPICE — протокол, который доставляет рабочий стол от виртуальной машины до пользователя. Открытый, бесплатный, дефолтный для всего Linux VDI. И при этом удивительно мало кто понимает, как он устроен внутри.

Почему курсор передаётся отдельным каналом? Зачем нужен глобальный словарь в GLZ? Как современные композитные менеджеры сломали красивую идею 2D-команд QXL?

Разбираю архитектуру SPICE — не список фич, а инженерные решения и их последствия. Первая статья серии.