compositingActive not efficient on XRandR events

[Alex Fiestas]

On 07/18/2011 11:53 AM, Aaron J. Seigo wrote:
> * a race condition as Alex outlined. if kwin is indeed responding to each
> xrandr even with a change in the CM, that seems like a perfect candidate for
> event compression if at all possible: don't tell the world outside that things
> have changed until the events have stopped coming in. the timeout for this
> shouldn't need to be long at all, so the user shouldn't see a big change at
> all
That's alrady done in one of my local branches (Martin knows about it), 
the thing
is that part of the code is sensible to breakages so Martin doesn't want 
to merge it until 4.8 and for 4.8 I plan to properly fix the situation 
(ergo the workaround of unifying the events will be useless).
> * KSelectionWatcher itself and/or kwin's setting of the atom could be broken.
> in times past we've had isses where the KSelectionWatcher object simply did
> not emit any signals at all when kwin changed compositing.

As Martin pointed, the issue happens simply by restarting 
KWin/Composite, it is kinda random...
Also after a screenlocker I usually see this behavior.