私は「リモートスクリーンキャスティング」アプリケーションを開発しています (VNC と同じですが、正確ではありません)。ここでは、更新された画面ピクセルのタイルをネットワーク経由で転送します。キャッシュメカニズムを実装したいのですが、あなたの推奨事項を聞きたいです...
これが私がそれを行うべきだと思う方法です。タイル座標ごとに、更新されたタイルを追加する固定サイズのスタック (キャッシュ) があります。保存するとき、タイル データ (つまり、ピクセル) のある種のチェックサム (おそらく CRC-16 で十分でしょう?) を計算します。(デスクトップの新しいスクリーンショットから) 新しいタイルを取得すると、そのチェックサムを計算し、そのタイル座標のスタック内のすべての項目のチェックサムと比較します。チェックサムが一致する場合、タイルを送信する代わりに、「位置 X のキャッシュ スタックからタイルを取得」などの特別なメッセージを送信します。これは、サーバーとクライアントで同一のキャッシュ スタックが必要であることを意味します。
ここに私の質問があります：
デフォルトのスタック サイズ (深さ) は? スタック サイズが 5 の場合、これは指定された座標の最後の 5 つのタイルが保存され、画面ピクセルの解像度の 5 倍が合計キャッシュ サイズになることを意味します。大画面の場合、画面の生の RGB バッファは約になります。5 メガバイトなので、10 レベルのスタックを持つことは 50 MB のキャッシュを意味しますよね? では、キャッシュの深さはどうあるべきでしょうか? たぶん10だと思いますが、あなたの提案が必要です。
ネットワーク経由で送信する前に、タイルを JPEG に圧縮しています。圧縮前に JPEG タイルまたは生の RBG タイルのキャッシュを実装する必要がありますか? 論理的な選択は、キャッシュにあるタイルの不要な JPEG エンコードを回避するため、生のタイルをキャッシュすることです。ただし、RGB ピクセルを保存するには、はるかに大きなキャッシュ サイズが必要です。では、最適なオプションは何ですか?圧縮前または圧縮後?
新しいスクリーン タイルとキャッシュ スタック内のタイルを比較するには、CRC-16 チェックサムだけで十分ですか? CRC が一致する場合、タイルのバイトごとの比較を追加する必要がありますか、それとも冗長ですか? 衝突確率は破棄できるほど低いか?
一般的に、私が説明したスキームについてどう思いますか? その中で何を変えますか？どんな種類の提案もいただければ幸いです！