DE69328811T2 - Opcode abhängige Komprimierung für ein Window-System. - Google Patents

Description

Hintergrund der Erfindung
• Die vorliegende Erfindung bezieht sich auf die Datenkompression und insbesondere auf eine befehlscodespezifische Kompression für Fenstersysteme, die den Durchsatz und die Leistung von Fensteranwendungen erhöht, wenn häufig benutzte Befehlscodes (opcodes) und Befehlscodesequenzen komprimiert werden.
• Ein vom Massachusetts Institute of Technology (MIT) in Cambridge, Massachussetts, Vereinigte Staaten von Amerika, gesponsertes Konsortium schlug das X-Window-System für Grafiksysteme vor, das es separaten Anwendungen scheinbar gleichzeitig zu laufen ermöglicht, wie es im "X Window System - CLibrary and Protocol Reference" von Robert W. Scheifler et al. beschrieben ist, das von Digital Press veröffentlicht wurde. Jede Anwendung wird auf einem Computer abgearbeitet und auf einer Grafikanzeige innerhalb eines oder mehrerer "Fenster" auf der Anzeige angezeigt. Die verschiedenen Anwendungen oder Clients sind mit einem Anzeige- Server über einen bidirektionalen Datenpfad gekoppelt, wie beispielsweise ein lokales Netzwerk oder eine Fernkommunikationsverbindung, die Telefonleitungen einschließt. Der Anzeige-Server formatiert Anforderungen aus den Clients für eine richtige Anzeige innerhalb des richtigen Fensters bzw. der richtigen Fenster. Der Anzeige-Server stellt wiederum X- Erwiderungen, Ereignisse und Fehler zurück an die Clients zur Verfügung. Die Anforderungen aus den Clients umfassen eine Verbindungsanforderung, die um einen Zugriff auf die Anzeige bittet, und Datenanforderungen zum Übertragen von Daten und Text an den Anzeige-Server. Die Kommunikation zwischen dem Anzeige-Server und den Clients wird über ein X- Wire-Protokoll ausgeführt. Die Anforderungen in dem X-Window-System umfassen mehrere Bytes, die ein Anforderungskopfteil (header) und eine variable Anzahl nachfolgender Bytes einschließen. Das X-Wire-Protokoll ist nicht kompakt und nicht für eine hocheffiziente Datenübertragung ausgebildet. Die X-Wire-Daten können durch Fernkommunikationseinrichtungen, wie beispielsweise Modems, komprimiert und dekomprimiert werden, aber die interaktive Kommunikation, Kompression und Fehlerkorrektur bewirken eine Latenz bei dem Umlauf, d. h. verlangsamen die Kommunikation. So kann insbesondere bei Kanälen geringer Bandbreite, wie beispielsweise Fernkommunikationsverbindungen, die Kommunikation zwischen dem Anzeige-Server und den Clients ziemlich langsam sein. Folglich wird irgendeine Form der Datenkompression vor der Kommunikationsverbindung gewünscht, um die Interaktion zwischen dem Client und dem Anzeige-Server zu beschleunigen.
• Frühere auf X-Window-Systeme angewendete Kompressionstechniken umfassen die Verwendung eines generischen Kompressionsalgorithmus, wie beispielsweise den UNIX-LZW-Algorithmus, der von Terry A. Welch in "A Technique for High Performance Data Compression", IEEE Computer, Band 17, Nr. 6, Juni 1984, Seiten 8-19, beschrieben wird. Ein anderer Algorithmus, der entweder separat oder in Verbindung mit dem generischen Kompressionsalgorithmus verwendet worden ist, ist ein Delta-Codierungs- oder Differenzdatensatz-Codierungsalgorithmus, wie er im Abschnitt 7.0 von "X Remote and Terminal Services" von Kevin Paul Herbert in den Konferenzunterlagen der Silicon Valley Networkung Conference (SVNC) von 1991 beschrieben ist. Zusätzliche Algorithmen, die auf dem X Window Consortium E-Mail-Network vorgeschlagen worden sind, umfassen das Entfernen nicht verwendeter Bytes und spezielle Bitabbildungskompressionsalgorithmen für Bilder. Sämtliche dieser Kompressionstechniken unterstützen die Beschleunigung der Kommunikation zwischen Clients und dem Anzeige-Server, aber es sind weitere Geschwindigkeitsverbesserungen insbesondere für Kanäle geringer Bandbreite erwünscht.
Zusammenfassende Darstellung der Erfindung
• Dementsprechend schafft die vorliegende Erfindung eine befehlscodespezifische Kompression für Fenstersystemanwendungen, die die Protokollnachrichten weiter komprimiert, um die Leistung von Fensteranwendungen bei Kanälen geringer Bandbreite zu verbessern. An der Schnittstelle zwischen einem Client oder einer X-Window-Anwendung und einem Anzeige- Server kann die Kompression entweder durch die X-Library- Funktionen oder durch einen Proxy-Server angewendet werden. Der Proxy-Server ist mit einem Computer oder mit Computern gekoppelt, auf welchem bzw. welchen sich Clients aufhalten, und darüber hinaus mit einer Server-Schnittstelle über eine Kommunikationsverbindung. Der Proxy-Server komprimiert die Anforderungen aus den Clients für die Anzeigeschnittstelle in Datenpakete, die an die Server-Schnittstelle über die Kommunikationsverbindung gesendet werden. Die Server- Schnittstelle komprimiert dann die Daten und leitet die Daten aus den Datenpaketen an geeignete Client-Dateneingänge eines Anzeige-Servers weiter. Der Anzeige-Server verarbeitet die Daten für jeden Client und stellt die verarbeiteten Daten in dem (den) geeigneten "Fenster(n)" auf einer Anzeigeeinrichtung zur Verfügung. Erwiderungen, Ereignisse und Fehler aus der Anzeigeeinrichtung werden in gleicher Weise von der Server-Schnittstelle komprimiert, über die Kommunikationsverbindung in Form von Datenpaketen an den Proxy-Server übermittelt und dekomprimiert und an den richtigen Client gelenkt.
• Spezielle X-Befehlscodes umfassen PolySegment, PolyLine, PolyRectangle, PolyFillRectangle und ImageText8. Die oben genannten Poly-Befehlscodes umfassen ein Anforderungskopfteil (header) gefolgt von Datenpaaren, wobei jedes Datenpaar zwei 16-Bit-Datenwerte oder 4 Datenbytes aufweist. Sie werden auf ähnliche Weise verarbeitet, indem drei Durchläufe durch N ähnliche Paare von Daten aus jeder X-Anforderung genommen werden. Die drei Durchläufe werden gemacht, um zu bestimmen, ob Anzeigepaare darstellende Daten innerhalb der Anforderung aus 4 Bytes pro Datenpaar (zwei 16-bit-Datenwerte) in 2 Bytes pro Datenpaar (zwei 8-Bit-Datenwerte) reduziert werden können, sowie um die Anzahl der wiederholten Datenpaare zu bestimmen. Der erste Durchlauf (pass) sieht die Daten "wie sie sind" durch. Der zweite Durchlauf codiert die Datenpaare in bezug auf ein erstes Datenpaar. Der dritte Durchlauf codiert die ursprünglichen Datenpaare relativ zu dem letzten (vorhergehenden) Datenpaar. Der Durchlauf, der die größte Anzahl von Zwei-Byte-Datenpaaren und/oder die meisten sich wiederholenden Datenpaare erzeugt, wird ausgewählt, um die vollständige X-Anforderung zu bearbeiten. Für die vollständige X-Anforderung werden die Daten dann cachegespeichert, wie sie verarbeitet werden, und neue Datenpaare werden mit den Datenpaaren in dem Cache verglichen. In den codierten oder komprimierten Daten zeigt ein Identifiziererbyte an, ob jedes von zwei aufeinanderfolgenden Datenpaaren als 4-Byte-Werte, 2-Byte-Werte oder als das gleiche wie das vorhergehende Datenpaar in dem Cache definiert ist. Der richtige Wert für das Datenpaar (die Datenpaare) folgt dem Identifiziererbyte, wenn es nicht das gleiche wie das vorhergehende Datenpaar in dem Cache ist. In gleicher Weise werden die Anforderungskopfteile für aufeinanderfolgende Anforderungen verglichen, und sofern sie gleich sind, werden sie komprimiert, indem ein geeignetes unbenutztes Bit in den nachfolgenden Anforderungskopfteilführungsbytes gesetzt wird.
• Bei ImageText8-Daten sucht der Kompressionsalgorithmus nach identifizierten Sequenzen von Anforderungen mit spezifizierten wiederholten Datenmustern und reduziert eine identifizierte Sequenz in eine einzige komprimierte Anforderung. Die ImageText8-Verarbeitung sichert eine Anforderung für eine begrenzte, vorgegebene Zeitdauer, um eine Anforderungssequenz zu identifizieren. Ob eine ImageText8-Sequenz identifiziert wird oder nicht, der ImageText8-Kopfteil wird ebenso komprimiert, wie oben für die Datenpaar-Anforderungen erörtert wurde, indem Bits in den nachfolgenden ImageText8-Kopf teilführungsbytes gesetzt werden, wenn eine Übereinstimmung gefunden wird.
• Die Aufgaben, Vorteile und neuartigen Merkmale der vorliegenden Erfindung, wie sie in den anhängigen Ansprüchen definiert ist, werden aus der folgenden detaillierten Beschreibung, wenn sie im Zusammenhang mit den beigefügten Zeichnungen gelesen wird, ersichtlich.
Kurzbeschreibung der Zeichnung
• Fig. 1 ist eine Blockdarstellungsansicht eines X-Window- Systems gemäß der vorliegenden Erfindung.
• Fig. 2 ist eine Blockdarstellungsansicht eines Abschnitts einer Schnittstelle zwischen Clients und einem Anzeige-Server für das X-Window-System gemäß der vorliegenden Erfindung.
• Fig. 3 ist eine Darstellung der Bilddatenformate für das X-Window-System.
• Fig. 4 ist eine Darstellung eines unter Verwendung der vorliegenden Erfindung anzuzeigenden Bildes.
• Fig. 5 ist eine Darstellung der Daten für das Bild gemäß Fig. 4, die gemäß der vorliegenden Erfindung komprimiert sind.
• Fig. 6 ist eine Darstellung einer ImageText8-Sequenz von Anforderungen für das X-Window-System.
Beschreibung des bevorzugten Ausführungsbeispiels
• Es wird jetzt auf Fig. 1 Bezug genommen, in der ein X- Window-System gezeigt ist, das eine Mehrzahl von Client-Anwendungen 12 aufweist, die auf einem oder mehreren Computern ablaufen, ein Anzeigesystem mit einem Anzeige-Server 14 und eine Anzeigeeinrichtung 16 mit einer Mehrzahl von Fenstern 18, innerhalb welcher die Client-Anwendungen angezeigt werden. Die Ausgaben aus den Client-Anwendungen 12 im X-Wire- Protokoll werden einem Proxy-Server 20 oder einer XLibrary- Funktion innerhalb der Client-Anwendung eingegeben. Der Proxy-Server 20 verarbeitet die Eingaben aus den Client-An wendungen 12, um codierte, komprimierte Pakete der Daten zu erzeugen, die über eine Kommunikationsverbindung 22 an eine Server-Schnittstelle 24 gesendet werden. Die Server-Schnittstelle 24 decodiert und dekomprimiert die Datenpakete aus der Kommunikationsverbindung 22, um die ursprünglichen X- Wire-Protokollinformationen aus den Client-Anwendungen zu rekonstruieren. Die ursprünglichen X-Wire-Protokollinformationen werden dem Anzeige-Server 14 als Daten aus jeder Client-Anwendung 12 eingegeben. Der Anzeige-Server 14 verarbeitet die Daten aus jeder Client-Anwendung 12 für eine Anzeige in dem richtigen Fenster (den richtigen Fenstern) 18 auf der Anzeigeeinrichtung 16.
• Wie es in Fig. 2 gezeigt ist, sind die Konfiguration des Proxy-Servers 20 und der Server-Schnittstelle 24 im wesentlichen identisch, so daß nur eine im Detail beschrieben wird. Die X-Wire-Protokolldatenströme werden anfänglich einem X-befehlscodespezifischen Kompressionsalgorithmus/Codierer 32 eingegeben, wo die Daten komprimiert werden, wie es detaillierter unten beschrieben wird. Die anfänglich komprimierten Daten aus dem X-Befehlscode-Codierer 32 oder die ursprünglichen Daten, sofern keine Befehlscodekompression angewendet wird, werden einem Delta-Kompaktor (Verdichter) - Algorithmus 34 eingegeben. Die Daten am Eingang zu dem Delta-Kompaktor-Algorithmus 34 oder, in Abhängigkeit von der Länge der Daten, die aus dem Delta-Kompaktor-Algorithmus ausgegebenen Daten werden dann einem generischen Kompressionsalgorithmus 36 zur Kombination mit ähnlich komprimierten Daten aus oder für andere Client-Anwendungen 12 in Datenpakete mit einem Kopfteil (header) und einem Anhang (trailer) eingegeben und über die Kommunikationsleitung 22 übermittelt. Der Paket-Kopfteil enthält ein SOequenzbyte, das die Sequenznummer des Pakets in einem Strom von Paketen anzeigt, und ein Client-Anwendung-Identifikationsnummernbyte. Der Anhang (Trailer) enthält zwei zyklische Redundanzprüfungsbytes (CRC-Bytes) und ein spezielles Rahmenbyte. Es kann ein Byte in dem Paket von dem generischen Kompressionsalgorithmus 36 hinzugefügt werden, wenn die Quelle oder das Ziel der Daten innerhalb des Pakets von oder zu einer anderen Client-Anwendung umgeschaltet wird.
• Der Paketstrom wird durch den Proxy-Server/die Server- Schnittstelle 20/24 aus der Kommunikationsleitung 22 empfangen und decodiert. Der Kopfteil jedes Pakets wird für einen Vergleich mit dem Kopfteil des nächsten Pakets cache-gespeichert, um eine korrekte Sequenz von Paketen zu bestimmen, d. h., ob keine Pakete verlorengingen. Die Daten werden an einen generischen Dekompressionsalgorithmus 42 geleitet und dann an einen geeigneten Delta-Dekompaktionsalgorithmus 44 für den bestimmten Client, wenn angezeigt. Der sich ergebende Datenstrom aus dem generischen Dekompaktionsalgorithmus, sofern keine Delta-Dekompression angezeigt wird, oder aus dem Delta-Dekompressionsalgorithmus wird einem Xcode-spezifischen Dekompressionsdecodieralgorithmus 46 eingegeben, wenn angezeigt wird, daß das ursprüngliche X-Wire- Protokoll für oder aus jeder der Client-Anwendungen 12 rekonstruiert werden soll.
• Daten für Bilder können in dem X-Wire-Protokoll entweder als Liniensegmente, PolySegment, zusammenhängende Linien, PolyLine, oder als Rechtecke, PolyRectangle und PolyFill- Rectangle, übermittelt werden. Die Codierfunktion für jede dieser Anforderungstypen ist xspecEncodePolySeg, xspecEncodePolyLine oder xspecEncodePolyRect. Entsprechende Funktionen sind für die jeweiligen Anforderungsdecodierer vorhanden. Wie es in Fig. 3 gezeigt ist, hat eine PolySegment- X-Anforderung aus einer Client-Anwendung 12 einen Zwei-Teil- Anforderungskopfteil von 4 plus 12 Bytes, gefolgt von Paaren von xy-Datenpunkten, wobei jeder Datenpunkt die Koordinate für einen Endpunkt eines Liniensegments bestimmt. Die Anzahl der Datenpunktpaare für jede PolySegment-Anforderung ist in dem Kopfteil enthalten. Jede Koordinate für jeden Datenpunkt wird als ein 16-Bit(2-Byte)-Wert ausgedrückt, so daß die Definition eines Liniensegments 8 Bytes erfordert. Eine Poly- Line-X-Anforderung hat den gleichen Typ eines Kopfteils wie die PolySegment-X-Anforderung mit Ausnahme der Identifikation des Befehlscodetyps. Benachbarte Datenpunkte folgen dem Kopfteil, ausgedrückt in xy-Koordinaten, wobei der vorhergehende Punkt der Startpunkt für ein Liniensegment ist, das mit dem aktuellen Punkt endet. Schließlich ist eine Poly- Rectangle-X-Anforderung der Polysegment-X-Anforderung sehr ähnlich mit der Ausnahme, daß anstelle der Verbindung zweier Datenpunkte miteinander ein Startpunkt in xy-Koordinaten und ein Bereichsausdehnungswert in Form einer Höhe und einer Breite (hw) des Rechtecks das Datenpunktpaar bilden.
• Die Codierung einer PolySegment-X-Anforderung wird als Beispiel der Kompression/Codierung gemäß der vorliegenden Erfindung benutzt. Ein Bild, wie beispielsweise das in Fig. 4 gezeigte, weist eine Mehrzahl von Liniensegmenten auf, die angezeigt werden sollen. Dieses Bild wird ohne weiteres als ein Polysegment angezeigt, wobei das erste Liniensegmentpaar von Datenpunkten die Punkte (1), (2) sind. Nach dem Kopfteil werden die Datenpunkte in Paaren gruppiert, wie es in Fig. 3 gezeigt ist, wobei man sich numerisch vom Punkt (1) zum Punkt (14) bewegt. Die folgende Tabelle 1 liefert in Spalte A die Koordinatenwerte für jeden Datenpunkt des Bildes. TABELLE I
• Der erste Schritt der Codierung besteht darin, die ersten N Datenpunkte in der PolySegment-X-Anforderung zu verarbeiten. Die tatsächliche Anzahl der Datenpunkte in der Anforderung kann größer oder geringer als N sein. Sofern sie geringer als N ist, werden sämtliche Datenpunkte überprüft. Wie es in Fig. 5 gezeigt ist, enthält ein Teil des ersten Schritts einen ersten Durchlauf, in welchem die Datenpunkte "so wie sie sind" getestet werden, um zu sehen, wie viele auf ein einzelnes Byte reduziert werden können, d. h. einen Wert aufweisen, der geringer als dezimal 256 ist. Dann werden in einem zweiten Durchlauf sämtliche der Datenpunkte in bezug auf einen ersten Datenpunkt relativiert, und es wird die Anzahl der Datenpunkte, die jetzt auf ein einziges Byte reduziert werden können, getestet, d. h. die einen Wert im Bereich von +/-127 aufweisen. Schließlich werden in einem dritten Durchlauf die Datenpunkte in bezug auf den jeweils letzten Daten punkt relativiert und getestet, um zu bestimmen, wie viele auf ein einziges Byte reduziert werden können. Gemäß der obigen Tabelle I, Spalte A, können vier Datenpunkte in 8- Bit-Werten ausgedrückt werden, und unter Spalte C können 9 Datenpunkte in 8-Bit-Werten ausgedrückt werden. Dann wird die Anzahl der sich wiederholenden Datenpunkte für jeden Durchlauf bestimmt, um zu einer Effektivitätszahl (figure of merit) für die Codierung zu gelangen. Für die 14 Datenpunkte in den Spalten A und B gibt es keine sich wiederholenden Datenpunkte. Die Effektivitätszahl ist 14/14 = 1. Für die Spalte C gibt es sechs einzigartige Datenpunkte, so daß die Effektivitätszahl 14/6 = 2,33 ist. Auf der Grundlage dieser Analyse der ersten N Datenpunkte, wird die gesamte PolySegment-X-Anforderung relativiert zu dem letzten Datenpunkt verarbeitet, da diese Codiertechnik die größte Anzahl von Datenpunkten aufweist, die Werte haben, die auf ein einzelnes Datenbyte reduziert werden können, und die beste Effektivitätszahl für wiederholte Datenpunkte aufweist.
• Der zweite Schritt besteht darin, die vollständige Anforderung unter Verwendung der ausgewählten Codiertechnik zu komprimieren, bei diesem Beispiel die in Spalte C der Tabelle I dargestellte Technik. Wie es in Fig. 5 veranschaulicht ist, wird für jedes Paar der Datenpunkte ein Identifiziererbyte eingerichtet, bei dem die ersten vier Bits anzeigen, wie der Wert des ersten Datenpunkts des Paars bestimmt werden soll, und die letzten vier Bits anzeigen, wie der Wert des zweiten Datenpunkts des Paars bestimmt werden soll. Wenn die Datenpunkte empfangen werden, werden sie in einen Am-längsten-unbenutzt(LRU)-Ersetzungs-Cache-Speicher plaziert, so daß sich die jüngsten Datenpunkte beim Cachespeicherplatz 0 befinden. Bei diesem speziellen Beispiel werden zwei Konfigurationen von vier Bits, das binärcodierte Dezimal F und das binärcodierte Dezimal E reserviert, um anzuzeigen, daß der zugehörige Datenpunkt entweder zwei 16-Bit- Werte bzw. zwei 8-Bit-Werte ist, und der Wert folgt dem Indikatorbyte. Wenn jedoch der Datenpunkt der gleiche ist, wie ein Datenpunkt in dem Cache-Speicher, dann wird der den Index in den Cache darstellende Wert verwendet.
• Wendet man dies auf das Beispiel gemäß Tabelle I an, so hat der erste Datenpunkt eine Koordinate mit einem Wert außerhalb des Bereichs von +/- 127, wie auch der zweite Datenpunkt. Beim Datenpunkt (2) ist der Wert des Datenpunkts (1) im Speicherplatz 0 in dem Cache-Speicher, aber die Werte sind nicht gleich. Folglich hat das Identifiziererbyte für das erste Datenpunktpaar einen Wert "FF" und wird von den acht Bytes gefolgt, die die vier Werte der xy-Koordinaten des ersten Datenpunktpaars enthalten. Datenpunkt (3) wird mit den Speicherplätzen 0 und 1 in dem Cache-Speicher verglichen, die den Datenpunkten (2) bzw. (1) entsprechen. Da keine Gleichheit mit einem der beiden Punkten in dem Cache vorhanden ist und der Wert außerhalb des Bereichs +/- 127 liegt, wird "F" in den ersten Teil des nächsten Identifiziererbytes eingefügt. Jedoch hat der Datenpunkt (4) den gleichen Wert wie der Datenpunkt (2), welcher sich am Speicherplatz 1 in dem Cache-Speicher in bezug auf den Datenpunkt (4) befindet. Folglich ist der zweite Teil des nächsten Identifiziererbytes "1", so daß das Identifiziererbyte zu "F1" wird. Dem Identifiziererbyte folgen dann die vier Bytes, die erforderlich sind, um die Werte für den Datenpunkt (3) bereitzustellen. Das nächste Paar von Datenpunkten (5) und (6) hat keine gleichen Werte in dem Cache-Speicher, und der Datenpunkt (5) erfordert 16 Bits, während der Datenpunkt (6) nur 8 Bits erfordert. So wird der nächste Identifizierer zu "FE", gefolgt von 6 Bytes Datenwerten. Dem Prozeß entsprechend wird das nächste Paar Datenpunkte als "E1" plus die beiden Bytes für den Datenpunkt (7) komprimiert. Die abschließenden drei Paare Datenpunkte haben entsprechende Werte im Cache, so daß nur das Identifiziererbyte für jedes Paar erforderlich ist und jedes Identifiziererbyte "11" ist, da sich die gleichen Werte für jeden Datenpunkt am Cache-Speicherplatz 1 befinden. Dies komprimiert die Daten für 7 Liniensequente, die ursprünglich von 56 Bytes (4 Bytes pro Punkt mal 14 Punkten) zur Verfügung gestellt wurden, auf 27 Bytes.
• Auf ähnliche Weise kann eine PolyLine-X-Anforderung unter Verwendung aufeinanderfolgender Paare von Datenpunkten codiert und komprimiert werden, die Änderungen in der Richtung eines kontinuierlichen Linienbildes markieren. Der gleiche Prozeß findet auf eine PolyRectangle-X-Anforderung Anwendung. Beim Verarbeiten der PolyRectangle-X-Anforderung jedoch werden die Datenpunktkoordinatenwerte und Flächenausdehnungswerte separat codiert und zwei separaten Cache-Speichern während der Kompressionsphase gespeichert, so daß die Datenpunkte mit Datenpunkten und Bereichsausdehnungswerte mit Bereichsausdehnungswerten verglichen werden. Die erste Tetrade des Identifiziererbytes ist eine Datenkoordinatentetrade und die zweite Tetrade ist eine Bereichsausdehnungstetrade.
• Eine weitere Kompression kann durch Cache-Speicherung des Anforderungskopfteils von einer früheren X-Anforderung verwirklicht werden, um zu bestimmen, ob es eine Identität zwischen Kopfteilfeldern in aufeinanderfolgenden Anforderungen gibt. Wenn dies der Fall ist, werden geeignete, anderenfalls leere Bits, die anzeigen,. welche Kopfteilfelder sich nicht ändern, in den ersten vier Bytes des Kopfteils gesetzt und die zugehörigen Felder in den verbleibenden 12 Bytes des Kopfteils werden gelöscht.
• ImageText8 ist eine X-Anforderung zum Anzeigen von Textbildzeichen. Es gibt bestimmte gemeinsame Sequenzen, die beim Schreiben von Zeichen auf eine Anzeige auftreten. Eine derartige Sequenz ist eine Triade von X-Anforderungen zum Schreiben eines nächsten Zeichens auf eine Zeile angezeigten Textes, wie sie in Fig. 6 gezeigt ist. Die erste X-Anforderung löscht den Cursor auf der Anzeige, indem sie ein Leerzeichen bereitstellt, die zweite Anforderung schreibt das gewünschte Zeichen an den gleichen Ort auf der Anzeige und die dritte Anforderung schreibt den Cursor als Leerschritt mit einem abweichenden grafischen Context an den nächsten Ort auf die Anzeige. Das "D" in dem ImageText8-Format zeigt das Fenster an (X Window "zeichenbar"), "GC" zeigt einen Grafikkontext an, "xy" zeigt den Ort auf der Anzeige an und "TEXT" ist das an dem gekennzeichneten Ort mit dem speziellen Grafikkontext anzuzeigende Zeichen. Anforderung 1 R1 zeigt an, daß ein zeichenbares Zeichen an dem Ort (1) unter Verwendung des Graphikkontexts 1 geschrieben werden soll, wobei das Zeichen ein "Leerschritt" ist, um den gegenwärtig an diesem Ort befindlichen Cursor zu löschen. Anforderung 2 R2 zeigt an, daß ein zeichenbares Zeichen "B" an den gleichen Ort (1) unter Verwendung des gleichen Grafikkontextes geschrieben werden soll. Schließlich zeigt Anforderung 3 R3 an, daß ein zeichenbares Zeichen "Leerzeichen" an den nächsten Ort (2) unter Verwendung des Grafikkontextes 2, wie beispielsweise eine invertierte Anzeige, geschrieben werden soll, um den Cursor zu erzeugen. Eine Zustandsmaschine cache-speichert die erste Anforderung R1 für eine vorgegebene Zeitdauer und vergleicht nachfolgende Anforderungen mit gespeicherten Sequenzen, die mit der ersten Anforderung R1 beginnen. In dieser Situation wird dann, wenn eine zugehörige zweite Anforderung R2 gefunden wird, diese ebenfalls für eine vorgegebene Zeitdauer cache-gespeichert, um die dritte Anforderung R3 zu suchen. Wenn die drei Anforderungen innerhalb einer vorgegebenen Zeitdauer auftreten, dann wird eine Sequenz erkannt, und die Zustandsmaschine gibt eine verdichtete Anforderung aus, die die gesamte Sequenz repräsentiert. Auf diese Weise kann eine ImageText8-Sequenz von drei Anforderungen, die gewöhnlich 60 Bytes Daten erfordert, auf ein einziges komprimiertes Datenbyte plus Anforderungskopfteil reduziert werden. Wiederum kann eine weitere Reduktion erreicht werden, indem der Kopfteil der früheren Anforderung cache-gespeichert und die Anzahl der Bytes in dem Kopfteil von 16 auf vier Bytes reduziert wird, wenn die Arten der Anforderungen gleich sind. Dies kann ausgeführt werden, indem ImageText8-"xy" als ein Delta (Differenz) gegenüber den absoluten "xy" der verdichteten Anforderung codiert werden. Wenn dann die Kopfteilinformationen nachfolgender verdichteter Anforderungen verglichen werden, haben sie das gleiche Fenster ("D"), den gleichen Grafikkontext ("GC") und die gleichen Koordinaten ("xy", welche jetzt lediglich die Änderung der Position gegenüber der vorhergehenden Anforderung sind). Die Deltas sind für eine Textzeile, die inkrementell in dem Fenster angezeigt wird, konstant.
• Obwohl der Delta-Kompaktor 34 verwendet werden kann, um die Größe der verdichteten Anforderung zu reduzieren, resultiert eine weitere Verbesserung aus der Erkenntnis, daß die "Anforderungslänge" in dem Protokollkopfteil für ImageText8 redundant ist, da das "Länge-der-Zeichenkette"-Byte verwendet wird, um sie zu berechnen. Durch Verwendung der höher bewerteten Bits in "Länge-der-Zeichenkette" als Bit-Flags, 15 die eine Verdichtung anzeigen, kann die verdichtete Anforderung auf drei Bytes reduziert werden. In diesem Fall ist die Beschränkung des aktuellen Längenwerts auf wenige Bits geringer Ordnung akzeptabel, da lange Textzeichenketten nicht diejenigen sind, die einer Anforderungssequenzverdichtung unterzogen werden.
• Somit schafft die vorliegende Erfindung eine befehlscodespezifische Kompression für das Window-System durch Auswählen einer geeigneten Codiertechnik, Codieren des Befehlscodes in Übereinstimmung mit der ausgewählten Codiertechnik und weiteres Komprimieren des codierten Befehlscodes in Übereinstimmung mit Delta-Kompaktoren und generischen Kompressoren, um Datenpakete für eine Übertragung zwischen Client-Anwendungen auf einem oder mehreren Computern und Fenstern auf einer Anzeige zu bilden.

Claims (12)

1. Ein Verfahren zum Codieren einer Anforderung aus einer Client-Anwendung an einen Anzeige-Server, wobei die Anforderung von einer Art ist, die einen Mehr-Byte-Kopfteil und eine Mehrzahl von Zwei-Byte-Datenwerten aufweist, wobei die Paare von Datenwerten Datenpunkte repräsentieren, gemäß einem speziellen Protokoll, gekennzeichnet durch:

Auswählen einer Codierungstechnik auf der Grundlage einer ausgewählten Anzahl von Datenpunkten der Anforderung; und

Codieren der Anforderung gemäß der ausgewählten Codierungstechnik.

2. Ein Verfahren nach Anspruch 1, wobei der Auswahlschritt die Schritte umfaßt:

Reduzieren der Datenpunkte in eine Relativform;

Testen der Relativdatenpunkte für eine 8-Bit-Reduktion;

Überprüfen der Anzahl von Datenpunkten, die wiederholt werden, um eine Effektivitätszahl zu bestimmen; und

Bewerten der Ergebnisse des Reduktions-, Test- und Überprüfungsschritts, um die Codierungstechnik auszuwählen.

3. Ein Verfahren nach Anspruch 2, wobei der Reduktionsschritt den Schritt des Relativierens der Datenpunkte in bezug auf einen ersten Datenpunkt umfaßt.

4. Ein Verfahren nach Anspruch 2, wobei der Reduktionsschritt den Schritt des Relativierens der Datenpunkte in bezug auf jeweils einen letzten Datenpunkt umfaßt.

5. Ein Verfahren nach Anspruch 1, wobei der Auswahlschritt die Schritte umfaßt:

Reduzieren der ausgewählten Anzahl von Datenpunkten auf eine erste Relativform, indem die Datenpunkte gegenüber einem ersten Datenpunkt relativiert werden;

Testen der Datenpunkte in der ersten Relativform für eine 8-Bit-Reduktion;

Überprüfen hinsichtlich sich wiederholender Punkte bei den Datenpunkten in der ersten Relativform; und

Bewerten der Ergebnisse des Reduktions-, Test- und Überprüfungsschritts um festzustellen, ob die erste Relativform für den Codierschritt verwendet werden soll.

6. Das Verfahren nach Anspruch 5, wobei der Auswahlschritt ferner die Schritte umfaßt:

Wiederholen des Reduktions-, Test-, Überprüfungs- und Bewertungsschritts mit den Datenpunkten, die auf eine zweite Relativform reduziert wurden, indem die Datenpunkte gegenüber jeweils einem letzten Datenpunkt relativiert wurden, um festzustellen, ob die zweite Relativform für den Codierschritt verwendet werden soll; und

Verwenden der Datenpunkte ohne Reduktion für den Codierschritt, wenn weder die erste noch die zweite Relativform verwendbar sind.

7. Das Verfahren nach Anspruch 1, wobei der Codierschritt die Schritte umfaßt:

Aufbauen eines Identifizierbytes von zwei Tetraden für jedes Paar von Datenpunkten, wobei jede Tetrade einen Wert aufweist, der anzeigt, ob der zugehörige Datenpunkt ein 16- Bit-Wert, ein 8-Bit-Wert oder ein Zeiger in einen Am- Längsten-Unbenutzt-Ersetzungs-Cache ist;

Aktualisierung des Cache für jeden Datenpunkt; und Hinzufügen des geeigneten 16-Bit- oder 8-Bit-Werts für das Paar von Datenpunkten nach dem Identifiziererbyte, wenn die Datenpunkte kein cache-gespeicherter Datenpunkt sind.

8. Das Verfahren nach Anspruch 7, wobei der Aufbauschritt die Schritte umfaßt:

Anordnen eines "F" in der zugehörigen Tetrade, wenn der Datenpunkt ein 16-Bit-Wert ist;

Anordnen eines "E" in der zugehörigen Tetrade, wenn der Datenpunkt ein 8-Bit-Wert ist; und

Anordnen einer Nummer, die gleich einem Zeiger in den Cache ist, um einen wiederholten Datenwert anzuzeigen, wenn der Datenpunkt ein wiederholter Datenwert ist.

9. Eine Einrichtung zum Codieren spezieller Befehlscodes für ein X-Window-System einer Art, die eine Mehrzahl von Client-Anwendungen (12) und einen Anzeige-Server (14) aufweist, mit einer Anzeigeeinrichtung (16), die die Client- Anwendungen in Fenstern (18) anzeigt, und einer Kommunikationsverbindung (22), die zwischen den Client-Anwendungen und dem Anzeige-Server eingekoppelt ist, gekennzeichnet durch:

einen zwischen die Client-Anwendungen und die Kommunikationsverbindung eingekoppelten Proxy-Server (20) zum Codieren von Informationen aus den Client-Anwendungen für eine Übertragung über die Kommunikationsverbindung an den Anzeige-Server und zum Decodieren von Informationen, die aus dem Anzeige-Server über die Kommunikationsverbindung empfangen wurden; und

eine zwischen dem Anzeige-Server und der Kommunikationsverbindung eingekoppelte Server-Schnittstelle (24) zum Codieren von Informationen aus dem Anzeige-Server für eine Übertragung über die Kommunikationsverbindung an die Client- Anwendungen und zum Decodieren von Informationen, die aus den Client-Anwendungen über die Kommunikationsverbindung empfangen wurden;

wobei der Proxy-Server und die Server-Schnittstelle jeweils einen befehlscodespezifischen Codierer (32) zum Komprimieren der Informationen für eine Übertragung über die Kommunikationsverbindung sowie eine Delta-Verdichtung (34) und generische Kompressoren (36) aufweisen, um komprimierte Datenpakete zu erzeugen, die die Informationen während der Übertragung repräsentieren, und wobei sie jeweils einen befehlscodespezifischen Decodierer (46) zum Dekomprimieren der komprimierten Datenpakete, die aus der Kommunikationsverbindung empfangen wurden, sowie eine Delta-Entspannung (decompaction) (42) und generische Dekompressoren (42) aufweisen, um die Informationen zu reproduzieren.

10. Eine Einrichtung nach Anspruch 9, wobei der befehlscodespezifische Codierer des Proxy-Servers aufweist:

Mittel zum Auswählen einer Codiertechnik auf der Grundlage der Informationen; und

Mittel zum Codieren der Informationen in Zwischen-Datenpakete auf der Grundlage der ausgewählten Codiertechnik, wobei die Zwischen-Datenpakete mit anderen Zwischen-Datenpaketen durch den Delta-Verdichter (compactor) und generischen Kompressor kombiniert werden, um die komprimierten Datenpakete zu erzeugen.

11. Eine Einrichtung nach Anspruch 10, wobei der befehlscodespezifische Codierer des Proxy-Servers ferner aufweist:

Mittel zum Identifizieren spezieller Sequenzen von Informationen; und

Mittel zum Codieren der speziellen Sequenzen von Informationen in ein zweites Zwischen-Datenpaket entsprechend den identifizierten speziellen Sequenzen, wobei das zweite Zwischen-Datenpaket mit anderen Zwischen-Datenpaketen von dem Delta-Verdichter (compactor) und generischen Kompressor kombiniert wird, um die komprimierten Datenpakete zu erzeugen.

12. Eine Einrichtung nach Anspruch 9, wobei der befehlscodespezifische Codierer des Proxy-Servers aufweist:

Mittel zum Identifizieren spezieller Sequenzen von Informationen; und

Mittel zum Codieren der speziellen Sequenzen von Informationen in ein Zwischen-Datenpaket entsprechend der identifizierten speziellen Sequenz, wobei das Zwischen-Datenpaket mit anderen Zwischen-Datenpaketen von dem Delta-Verdichter und generischen Kompressor kombiniert wird, um die komprimierten Datenpakete zu erzeugen.