Benötigen Sie Hilfe Erläuterungen zu X11-Fensterhierarchie- und Zeichnungsbefehlen

Question

Ich arbeite an der Erstellung eines X11-Servers für Windows von Grund auf basierend auf einer Kopie des "X Protocol Reference Manual: Volume Zero". Ich habe große Fortschritte bei der Entschlüsselung der Nachrichten gemacht und eine bedeutungsvolle Konversation mit den Kunden gemacht, aber ich habe Schwierigkeiten zu verstehen, was die Zeichnungsaufrufe eigentlich tun sollten.

Die Nachrichten in diesem Beispiel stammen aus dem Ausführen von XBIFF auf einem Linux-Rechner und es hat mit meinem XServer unter Windows zu sprechen. Es ist durchaus möglich, dass ich bei der Interpretation des Protokolls etwas falsch verstanden habe, aber die Daten scheinen so gut zu sein.

Die Grafiken Anrufe mit diesen zu starten, mit dem Kunden einen Grafikkontext mit der Root-Fenster-ID (90) als ziehbar erstellen:

X_CreateGC: ID: 2097152, Drawable: 90, ValueMask: 8, Value0: 16777215 

Was die Bedeutung eine GC zu schaffen, basierend auf dem Root-Fenster ist ?

Als Nächstes erstellt es zwei 48x48 pixmaps und stellt Bilder auf sie:

X_CreatePixmap: Depth: 1, ID: 2097153, Drawable: 90, Width: 48, Height: 48 

X_CreateGC: ID: 2097154, Drawable: 2097153, ValueMask: 12, Value0: 1, Value1: 0 

X_PutImage: Format: 0, Size: 408, Drawable: 2097153, GraphicsContext: 2097154, Width: 48, Height: 48, X: 0, Y: 0, LeftPad: 0, Depth: 1 

X_FreeGC: Graphics Context: 2097154 

X_CreatePixmap: Depth: 1, id: 2097155, Drawable: 90, Width: 48, Height: 48 

X_CreateGC: ID: 2097156, Drawable: 2097155, ValueMask: 12, Value0: , Value1: 0 

X_PutImage: Format: 0, Size: 408, Drawable: 2097155, Graphics Context: 2097156, WIdth: 48, Height: 48, X: 0, Y: 0, LeftPad: 0, Depth: 1 

X_FreeGC: Graphics Context: 2097156 

Bin ich in der Annahme richtig, dass die GC in diesem ist das Äquivalent eines MemoryDC und das Endergebnis sollte zwei 48x48 Bitmaps werden in Speicher mit den Daten, die im PutImage-Aufruf enthalten waren?

Hier schafft es eine anderen Grafikkontext auf den Root-Fenstern basieren, aber ich verstehe nicht, warum:

X_CreateGC: ID: 2097157, Drawable: 90, ValueMask: 65544, Value0: 16777215, Value1: 0 

Als nächstes es zwei 48x48 Fenster erzeugt, eine mit der Wurzel als Mutter und dem nächsten mit der erstes Fenster als Mutter:

X_CreateWindow: Depth: 24, ID: 2097158, Parent: 90, X: 0, Y: 0, Width: 48, Height: 48, BorderWidth: 1, Class: 1, Visual: 0, Bitmask: 10266, Value0: 16777215, Value1: 0, Value2: 1, Value3: 6422576, Value4: 32 

X_CreateWindow: Depth: 24, ID: 2097161, Parent: 2097158, X: 0, Y: 0, Width: 48, Height: 48, BorderWidth: 0, Class: 1, Visual: 0, Bitmask: 26650, Value0: 16777215, Value1: 0, Value2: 0, Value3: 163852, Value4: 32, Value5: 0 

es scheint, wie dies ein 48x48 Basisfenster mit einem Fenster im Innern zu schaffen, die eine identische Größe und Ursprung hat. Was ist das für ein Gefühl? Wird das Unterfenster nicht gerade das Root-Fenster verdecken, was es zu einem redundanten Anruf macht?

Als nächstes erhalten wir einen CreatePixmap Anruf basierend auf dem Kindfenster oben gestaltet, mit einer Breite und Höhe von 0:

X_CreatePixmap: ID: 2097162, Drawable: 2097161, Width: 0, Height: 0 

Was ist der Zweck ist das?

Als nächstes erstellt xbiff (der Client) einen weiteren Grafikkontext basierend auf dem Child-Fenster und führt einen CopyPlane von einer der 48x48 Pixmaps aus.

X_CreateGC: ID: 2097163, Drawable: 2097161, ValueMask: 65544, Value0: 16777215, Value1: 0 

X_CopyPlane: SrcDrawable: 2097155, DestDrawable: 2097162, GraphicsContext: 2097163, SrcX: 0, SrcY: 0, DstX: 0, DstY: 0, Width: 0, Height: 0, Bitplane: 1 

X_FreeGC: 2097163 

Die Breite und Höhe sind 0 für diesen Aufruf. Ist das ein NOOP, oder bedeuten die Dimensionen 0x0 "alles kopieren"? Wenn dies der Fall ist, sollte dies nur die Bitmap in das Kindfenster blitten, richtig?

Als nächstes erstellt der Client eine 0x0 Pixmap auf das Kind Fenster basiert:

X_CreatePixmap: Depth: 24, ID: 2097164, Drawable: 2097161, Width: 0, Height: 0 

Was nützt ein 0x0 pixmap? Heißt das irgendwie "kopiere die Fenstermaße"?

Hier schaffen wir ein GC für das Kind Fenster und führen Sie eine CopyArea von einem der 48x48 Bitmaps zum Fenster:

X_CreateGC: ID: 2097165 Drawable: 2097161, ValueMask: 65548, Value0: 16777215, Value1: 0, Value2: 0 

X_CopyArea: SrcDrawable: 2097153, DestDrawable: 2097164, GraphicsContext: 2097165, SrcX: 0, SrcY: 0, DstX: 0, DstY: 0, Width: 0, Height: 0, Bitplane: 1 

Dieser CopyArea Aufruf auch eine Breite und Höhe von 0. Hat hat die "bedeuten Kopiere das Ganze? "

Als nächstes werden die Unterfenster von 2097158 (das übergeordnete Element, das an den Stamm angefügt ist) zugeordnet und dann das übergeordnete Element selbst zugeordnet.

X_MapSubwindows: Window: 2097158 
[We send a MapNotify and Expose event for window 2097161] 

X_MapWindow: Window: 2097158 
[We send a MapNotify and Expose event for window 2097158] 

Ich bin mir nicht sicher, warum es ClearArea auf das Kind Fenster hinterher ruft:

X_ClearArea: Window: 2097161, X: 0, Width: 0, Width: 0, Height: 0 

Ist das klar nichts oder das Ganze?

Dann ein CopyArea Anruf kopiert die 0x0 pixmap von früher das Kind Fenster an der Stelle 24x24:

X_CopyArea: SrcDrawable: 2097162, DestDrawable: 2097161, GraphicsContext: 2097157, SrcX: 0, SrcY: 0, DstX: 24, DstY: 24, Width: 0, Height: 0 

Breite und Höhe sind ebenfalls Null. Wiederum bin ich mir nicht sicher warum.

Ich wäre glücklich, etwas Hilfe zu haben, um zu verstehen, wie X11-Zeichnungsaufrufe funktionieren und warum die ungeraden (für mich) Anrufe so sind, wie sie sind.

Answer 1

(Die meisten davon können in der X Window System-Protokollspezifikation gefunden werden, die in many places im Internet frei verfügbar ist.)

Die Bedeutung einen GC relativ zum Root-Fenstern zu schaffen ist, dass ein Root-Fenster Benennt einen Bildschirm, und Bildschirme sind diese seltsame Sache in X, die einen Satz verwandter Zustände definieren. Pixmaps und Formate und Fenster und Grafiken und Colormaps usw. sind an einen bestimmten Bildschirm gebunden. Sie können mehrere Bildschirme haben; Wenn Sie das tun, können Fenster von einem nicht zu einem anderen wechseln. Dies ist die sogenannte "Zaphod" -Betriebsart. In den meisten gängigen Multihead-Setups haben Sie jedoch nur ein Hauptfenster, das mehrere Ausgänge abdeckt.

Die GC im PutImage Anruf bestimmt den Übertragungsmodus des Pixels im Bild zu dem Pixmap in dem Server: planemask, Clipping, Raster-op usw.

Sie sind, weil die Tiefe erstellt mehr GCs zu sehen eines GC ist eine statische Eigenschaft und nicht etwas, das Sie mit ChangeGC ändern können. Sie haben sowohl eine 1bpp-Pixmap als auch Windows- und Pixmaps, die die Tiefe des Root-Fensters geerbt haben. Daher benötigen sie unterschiedliche GCs.

Der Unterschied zwischen den beiden CreateWindow-Aufrufen liegt in der Maske der Eigenschaften, die jedem zugeordnet sind. Die zweite, relativ zu der ersten, hat auch das CWCursor-Bit gesetzt; Der Client fragt nach einem bestimmten Cursor, der gesetzt werden soll, wenn sich die Maus in diesem Fenster befindet. Warum es zwei so machen würde, habe ich keine Ahnung; Ich glaube nicht, dass jemals behauptet wurde, dass Xbiff gut geschrieben wurde.

0x0 ist keine legale Größe für eine Pixmap (oder irgendeine andere Zeichenkette), also bin ich mir nicht sicher, was dort vor sich geht. Die richtige Sache für den Server zu tun ist, BadValue in diesem Fall zu werfen, aber es scheint, dass das ein Symptom für etwas ist, das schief gegangen ist.

Answer 2

Nur um die ausgezeichnete Antwort von Ajax zu ergänzen. Beachten Sie, dass eines der Fenster einen Rahmen hat, das andere jedoch nicht. Und erinnern Sie sich, was genau xbiff tut (zeigen Sie ein "keine Mail" -Symbol oder ein "Sie haben Mail" -Symbol). Die zwei Fenster bieten einen Doppelpufferungseffekt. Um das Bild zu ändern, muss xbiff nur das untergeordnete Fenster (das ohne Rahmen) zuordnen oder die Zuordnung aufheben.