Was du brauchst ist eine Komprimierung die die Farbe "Transparent" ebenfalls effizient komprimieren kann.
Zb. mal RLE: dabei wird die Information übertragen Count, Farbe als Tupel. Das heist setze Count Pixels in Farbe. Für Farbe muß es jetzt einen speziellen OpCode geben der sagt "setze Count Pixels ohne Änderung" ergo: überspringe Count Pixels in der Zielbitmap.
Die Dekomprimierung lädt erstmal den aktuell gültigen Desktop und arbeitet dann die neuen Änderungen als RLE Datenstrom direkt darin ein.
Jetzt ist es aber nun so das auf einem normalen Desktop sich meistens rechteckige Bereiche verändern und deine Capture Funktion sowas mitbekommen kann. Also würdest du quasi die Region der Änderungen in einzeln zu ändernde Rechtecke zerlegen und dann diese als Metadaten und RLE Kodierung zu jedem Rechteck verpacken und senden. Das Datenformat dürfte dann inetwa so aussehen:
Code:
Anzahl Rechtecke
Prüfsumme
X,Y,W,H des 1. Rechteckes
RLE Daten des 1. Rechteckes
X,Y,W,H des 2. Rechteckes
RLE Daten des 2. Rechteckes
...
X,Y,W,H des x. Rechtecks
RLE Daten des x. Rechecks
Diese Metadaten schiebst du dann noch durch eine Huffman Komprimierung.
Beim Entkomprimieren der Daten zuerst die Huffman Dekodierung, danach die metadaten qausi als Arbeitsanweisung abarbeiten. D.h. lade Originalbild in voller Auflösung in den Speicher, springe an X,Y des 1. Rechtecks in diesen Speicher, entkomprimiere aus RLE Daten W Pixels, erhöhe Addresszeiger um Desktopbreite - W Pixel, entkomprimiere wiederum die nächsten W Pixels der 2. Pixedlzeile des Rechtecks usw. usw. bis du das H Zeilen oft gemacht hast. Dann laden nächste Daten des 2. Rechtecks bis zum X. Rechteck.
Im Grunde ist das sowas wie die Interlaced GIFs bei denen ein Bild in 2 Halbbildern übertragen wird, nur diesesmal wird ein Bild in freiwählbare recheckige Ausschnitte unterteilt und diese könnten sequientiell übertragen werden.
Du benötigst nun einen cleveren Komprimierungsalgo. der die entstandenen Differenzen zweier Bilder so in eine Kette von Rechteckigen Bereichen unterteilen kann das das beste Komprimierungsverhältnis herauskommen muß. Das heist du darfst bei wenigen Pixeländerungen nicht für jeden einzelnen Pixel ein Rechteck speichern, da ja die Koordinaten wie X,Y,W,H zb. jeweils 16 Bits benötigen. Das wäre für 1 Pixel Änderung zuviel Overhead.
[edit]
Oder noch besser:
Dein Desktop Rechteck wird rekursiv in 4 Rechtecke geteilt, diese 4 Rechtecke wiederum in 4 Rechtecke usw. usw.
Bei 800x600 also
Code:
1024x1024
512x512
256x256
128x128
64x64
32x32
16x16
8x8
Man hat also 8 verschiedene Größen von Rechtecken und ermittelt nun die Differenzen der beiden Bilder innerhalb dieser Matrix. Dein Header zur Angabe der Größe eines Rechteckes benötigt nun nur noch 3 Bytes für
[Code]
Rechteck Größe aus obiger Liste, Wert 0 bis 7
X,Y Koordinate dieses Rechtecks, X * Pixelgröße[Rechteckgröße] ergibt reale X Koordinate.
[\Code]
[/edit]
Gruß Hagen