Xflush Alternative gesucht

Post Reply
Message
Author
grisu1972
Posts: 16
Joined: 22. Jul 2008 11:03

Xflush Alternative gesucht

#1 Post by grisu1972 »

Hallo Leute,

ich habe bis jetzt immer ein XFlush(display); benutzt um eine XLib Aktion wie XSendEvent (display, tmpWin, False, 0L, &xev) abzuschließen!
Das finde ich eigentlich etwas hart, gibt es eine bessere Methode?

Grüsse Carsten

User avatar
Janka
Posts: 3585
Joined: 11. Feb 2006 19:10

#2 Post by Janka »

XFlush() sendet alle Client-Anforderungen in einem Rutsch vom Client zum Server, um die Zahl der Requests zu verringern. Genau dafür ist das gemacht. Was ist daran bitte "hart"?

Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.

grisu1972
Posts: 16
Joined: 22. Jul 2008 11:03

#3 Post by grisu1972 »

Genau darin besteht mein "Problem"!
Wenn ich asynchron etwas an den XServer schicken möchte wird alles geschickt was zuvor zusammengebaut wurde.
Bsp.
Es soll etwas anzeigt werden, zwischendurch wird ein signal empfangen!
Das signal wird abgearbeitet und sendet etwas an den XServer, damit der XServer das sofort erhält wird ein xflush() aufgerufen(!). Dann würde das, was zuvor vorbereitet wurde auch gleich gesendet! Nach der Abarbeitung würde die Applikation die Anzeige weiter abarbeiten!
Mir ist einfach unklar, was für Auswirkungen dieses asynchrone bearbeiten des Signals verursachen kann! Ich gehe davon aus das es nicht unproblematisch ist, weiss aber auch nicht wie ich dem entgegenwirkenn könnte!

In meinem Verständnis ist dies in der Realisierung der XtAppMainLoop zu suchen, wenn ein Signal asynchron abgearbeitet wird kann es halt die Methode in der sich die Mainloop befindet unterbrechen!
Das ist doch so, oder habe ich das falsch verstanden?

User avatar
Janka
Posts: 3585
Joined: 11. Feb 2006 19:10

#4 Post by Janka »

Du kannst die Requestqueue zum XServer übertragen, so oft du willst. Es gibt keine Transaktionssemantik, das heißt: Dem Xserver ist es egal, welche Requests innerhalb eines Request-Blocks zusammengefasst sind, die werden auf der Empfangsseite sowieso einfach wieder in eine Queue eingetütet.

Wenn du in deinem Programmablauf eine bestimmte Reihenfolge der Event-Bearbeitung erzwingen musst, musst du jeweils einen "Round-Trip" erzeugen, das heißt, die Event-Verarbeitungsroutine erzeugt wieder einen neuen Event für den nächsten Schritt. Damit ist die Reihenfolge dann festgenagelt.

Das fehlen der Transaktionen ist auch ein Grund dafür, dass X in solchen Abläufen sehr langsam sein kann. Am besten vermeidet man Abläufe mit fester Reihenfolge.

Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.

Post Reply