Zitat:
Der Rest Deines Vorschlages deckt sich (wie üblich) mit Meinen weiter oben erwähnten Ideen (oder umgekehrt). Die rekursive Herangehensweise ist interessant, wird aber nicht sonderlich performant sein, da Du vor dem rekursiven Abstieg wissen musst, ob sich überhaupt etwas im aktuellen Quadranten geändert hat. Wenn ja, unterteilst Du den Quadranten und analysierst das Ganze doch nochmal...
der Gedankenansatz ist rekursiv aber NICHT die Implementierung !
Der Denkansatz ist deshalb rekursiv und eine Exponentation zur Basis 2 weil so die geringste Komplexität von O(ln2(n)^2) rauskommt, also schon eine ziemlich gute Komplexität.
Das heist aber nicht das man rekursiv nun das ganze implementiert. Umgedreht sollte es implementiert werden. Beim Auftreten einer Menge von geänderten Pixeln werden diese Pixel solange zu Rechtecken a 2^i Breite und Höhe zusamengefasst wie sich das entstehende Komprimierungsverhältnis noch als schlecht herausstellt. Sobald das Komprimierungsverhältnis also besser 2 oder 3 etc.pp wird hört man mit der Zusammenfassung dieser Rechtecke auf.
Da wir in unserem Datenstrom nun eine reine RLE Codierung benutzen (übrigens eine der einfachsten und effizientesten Komprimierung von sequientiellen Bitmapdatenströmen) würde man anschließend auf diesen RLE Datenstrom mit LZW arbeiten. Man entfernt mit LZW also redunante RLE Codeketten. Danach kann man effektiv nur noch Huffman darauf anwenden.
Aber ich glaube das LZW/Huffman im Grunde garnicht notwendig ist, wenn man das zeitliche Updateinterval hoch wählt. Das heist man überträgt immer sehr schnell die wenigen rechecktigen Änderungen zwischen den Bitmaps. Und das wird möglich weil in einem Fensterorientierten Betriebsystem die Änderungen an den Bitmaps ebenfalls sehr wahrscheinlich immer rechteckig sind.
Eines steht fest: diese Art der Komprimierung wird als verlustfreie Komprimierung JEDE normale Komprimierung wie GIF, BMP, PNG outperformen müssen. Einfach weil wir schon in advance uns spezielles Wissen über die Häufigkeit und Art der Änderungen Gedanken gemacht haben und diese in unserer Komprimierung einfließen lassen.
Nur noch verlustbehaftete Algorithmen wie MPEG in Videos kann das übertreffen.
Ausser man macht es wie zb. Windows und hookt alle
GDI Operationen. Man fängt also alle Grafikoperationen der Prozesse auf dem Desktop ab und überträgt wie in einem Metafile nur die auszuführenden Operationen als Befehlssequenzen. Statt also das Resultat von zb. DrawText(100,200, 'Test') als Pixels zu übertragen wird direkt der Befehl "zeiche an 100,200 den Text 'Test'" übertragen. Das ist Informationstheoretisch am besten und ermöglicht die beste Komprimierung !
Gruß Hagen