Управление памятью при хранении буфера изображения с хешем в программе совместного использования экрана

Question

Редактировать: Я не получаю достаточного ответа на этот вопрос, возможно, я не могу правильно объяснить.Позвольте мне попытаться объяснить предысторию этого вопроса.

В каждой программе совместного использования экрана есть две стороны.Сервер и средство просмотра.

Сервер

Роль сервера

• экран рабочего стола захвата
• сравнение экрана захвата с предыдущим отправленнымscreen
• вычисление грязной области, преобразование грязной области в байтовый массив
• отправка байтового массива в TCP-сокет для просмотра

Просмотр

Роль зрителя

• получение байтов с сервера
• преобразование байтов в изображение
• Рисование изображения в окне просмотра / панели просмотра

Проблема для решения

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

Ниже приведен мой анализ

Я изучаю, как работает приложение для передачи экрана, такое как Team Viewer, Любой рабочий стол, и выясняю, как оно работает при подключении к Интернету с очень низкой пропускной способностью.

Покаучась я наткнулся на приложение для обмена экранами Any Desk .Который использует xxHash для хеширования изображений и отправки байтовых данных изображения вместе с его хэш-кодом.

Я использовал монитор скорости сети в моем мобильном интернете и запустил приложение.

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

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

Редактировать

Программа совместного использования экрана не отправляет весь экран / Регион каждый раз. Она просто отправляет только разницу / Грязный номер через Интернет. Вместе сесли у пользователя очень плохое подключение к Интернету, он сохраняет байтовый массив каждого кадра / региона вместе с хэш-кодом. Отправлять только хэш-код, если hascode совпадает с разным кадром / регионом bytearray

Предположение кода сервера

     List<uint> hashlist = new List<uint>();
        byte[] imagesBytestosend = GetImageBytes();

        uint hash = XXHash.XXH32(imagesBytestosend);

        if (!hashlist.Contains(hash))
        {
           hashlist.Add(hash);
          SendAllBytesData(imagesBytestosend);
        }
        else
        {
           SendOnlyHasCode(hash);

        }

КлиентКод предположения

    Dictionary<uint, byte[]> frameData = new Dictionary<uint, byte[]>();
        bytes[] imageBytes = null;
        if(frameData.ContainsKey(receivedHash))
        {
        imageBytes=frameData[receivedHash];
        }
        else
        {
        imageBytes=receivedBytes;;
        frameData.Add(receivedHash, receivedBytes);
        //My Question is how this is memory efficient to store frame bytes with his hash code in memory
        }
        DrawToPictureBox(imageBytes);

Answer 1

Похоже, у вас есть фундаментальное отсутствие понимания того, как работает общий доступ к экрану. Например, в Windows мы не обнаруживаем изменений в буфере экрана. Вместо этого мы полагаемся, что Windows помечает области экрана как недействительные.

https://docs.microsoft.com/en-us/windows/desktop/gdi/the-update-region

Вы можете заметить, что при включении общего доступа к экрану тема Windows переключается с Aero на Основные темы.

Answer 2

Если изображение все еще открыто, то оно все еще находится в памяти на стороне клиента. Таким образом, единственные издержки - это хеш-код, который довольно мал. Во всяком случае, это эффективно в сценарии, который вы описали. Если хеш-код не был сохранен, то то же изображение (которое уже находится в памяти) будет отправлено снова, что приведет к потере пропускной способности и приведет к проблемам с производительностью. Однако, поскольку хэш сохранен, клиенту нужно только перерисовать одно и то же изображение из байтов в памяти.

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