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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

Вы можете проверить реализацию кэша x11vnc .