On Tue, Sep 16, 2014 at 08:35:41PM +0100, Dominik Vogt wrote: > How does the attached experimental patch work for you?
Let me explain how the patch works: When the former flush_property_notify functions is called, I know Use the library function FCheckPeekIfEvent (but XCheckEvent would do as well) and give it a special predicate routing (see below). The Xlib call will then walk over the queue once and call the predicate for each event. The predicate routine gets a pointer to the event. I have just assumed that pointer is a pointer to the *original* event in the queue, and I can alter an event while its still in the queue. This is totally undocumented but seems to work with X.org. The predicate routine checks if the event at hand is a PropertyNotify event with the atom it's looking for, and if so, sets the atom field of the event structure to None. In any case the predicate returns False, so for Xlib it will look as if there wasn't a match at all in the queue. Then, right after reading the event from the queue, I check if it's a PropertyNotify event and the atom is None. If so, the loop is simply restarted, throwing away the event. I don't think I can make it faster than that, but there's really no guarantee that it works with a given Xlib implementation. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
