Нужны предложения по механизму кэширования плитки в VNC-подобном приложении

Я разрабатываю приложение «удаленного просмотра экрана» (точно так же, как VNC, но не совсем), в котором я передаю обновленные фрагменты пикселей экрана по сети. Я бы хотел реализовать механизм кеширования и хотел бы услышать ваши рекомендации ...

Вот как, я думаю, это нужно делать. Для каждой координаты плитки есть стек фиксированного размера (кеш), куда я добавляю обновленные плитки. При сохранении я вычисляю какую-то контрольную сумму (вероятно, CRC-16 будет достаточно, не так ли?) Данных плитки (то есть пикселей). При получении новой плитки (из нового снимка экрана рабочего стола) я вычисляю ее контрольную сумму и сравниваю с контрольными суммами всех элементов в стеке с координатами этой плитки. Если контрольная сумма совпадает, вместо отправки плитки я отправляю специальное сообщение, например. "получить тайл из стека кеша в позиции X". Это означает, что мне нужны одинаковые стеки кеша на сервере и на клиенте.

Вот мои вопросы:

  • Каким должен быть размер стека (глубина) по умолчанию? Скажем, если размер стека равен 5, это означает, что будут сохранены последние 5 плиток с указанными координатами, и 5-кратное разрешение пикселей экрана будет общим размером кеша. Для больших экранов необработанный буфер RGB экрана будет составлять прибл. 5 мегабайт, так что наличие 10-уровневого стека означает 50 МБ кеш-памяти, верно? Так какой же должна быть глубина кеша? Я думаю, может быть, 10, но нужны ваши предложения.

  • Я сжимаю плитки в JPEG перед отправкой по сети. Следует ли реализовать кэширование фрагментов JPEG или необработанных фрагментов RBG перед сжатием? Логическим выбором будет кэширование необработанных тайлов, поскольку это позволит избежать ненужного кодирования JPEG для тайлов, которые могут быть найдены в кеше. Но для сохранения пикселей RGB потребуется гораздо больший размер кеша. Итак, какой вариант лучше - до или после сжатия?

  • Достаточно ли одной контрольной суммы CRC-16 для сравнения новых плиток экрана с плитками в стеке кеша? Я имею в виду, следует ли мне дополнительно проводить побайтовое сравнение плиток, когда CRC совпадает, или это избыточно? Достаточно ли мала вероятность столкновения, чтобы от нее можно было отказаться?

  • В общем, как вы относитесь к описанной мной схеме? Что бы вы в нем изменили? Будем признательны за любые предложения!


c++ caching bitmap vnc
person TX_    schedule 09.06.2011    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Мне нравится, как вы все объяснили, это, безусловно, хорошая идея для реализации.

Пару месяцев назад я реализовал аналогичный подход для аналогичного приложения. Сейчас ищу другие схемы, которые работают вместе с ним или заменяют его.

Я использовал размер стека кэша, равный количеству плиток, присутствующих на экране, и не ограничивал плитку, которая должна совпадать с тем же местоположением предыдущей плитки. Я полагаю, это очень полезно, когда пользователь перемещает окно. Размер кеша - это компромисс между вычислительной мощностью, памятью и пропускной способностью. Чем больше плиток у вас в кеше, тем больше вы можете снова сэкономить полосу пропускания за счет затрат на память и обработку.

Я тоже использовал CRC16, но это не идеально для реализации, поскольку когда он попадает в некоторые CRC в кеше, он создает очень странное изображение, которое довольно раздражает, но очень редко. Лучше всего совпадать пиксель за пикселем, если вы можете себе это позволить с точки зрения вычислительной мощности. В моем случае я не мог.

Кэширование JPEG - лучшая идея для экономии памяти, потому что, если мы создаем BITMAP из JPEG, ущерб уже был нанесен с точки зрения качества, я предполагаю, что вероятность неправильного CRC одинакова в обоих случаях. В моем случае я использовал JPEG.

person Syed Ashar Akhtar    schedule 29.07.2011

arrow_upward
1
arrow_downward

Я бы использовал более быстрый алгоритм хеширования. murmur2 или Jenkins, например. Это обещает гораздо лучшую уникальность. См. Удаленный протокол Spice (www.spice-space.org) для примера кеширования. Кеш должен быть максимально большим (на клиенте или на промежуточном прокси).

person Yaniv    schedule 21.02.2012

arrow_upward
0
arrow_downward

Вы можете ознакомиться с реализацией кэша x11vnc.

person genpfault    schedule 09.06.2011