Page 1 of 1

Xflush Alternative gesucht

Posted: 15. Aug 2008 7:50
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

Posted: 15. Aug 2008 9:56
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

Posted: 15. Aug 2008 14:27
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?

Posted: 15. Aug 2008 19:42
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