compositingActive not efficient on XRandR events

[Sebastian Kügler]

On Monday, July 18, 2011 15:12:29 Fredrik Höglund wrote:
> On Monday 18 July 2011, Aaron J. Seigo wrote:
> > On Saturday, July 16, 2011 15:36:19 Martin Gräßlin wrote:
> > > The bug is much simpler - Plasma just simply fails to recognize that a
> > > compositing manager is active. I can see this each time I restart kwin
> > > (which is considerable often). In order to get translucent panels back,
> > > I have to kquitapp plasma-desktop, plasma-desktop.
> > 
> > Plasma::Theme uses a KSelectionWatcher which watches _NET_WM_CM_S# where
> > # is the number of the default screen.
> > 
> > i can imagine a few things going wrong with this:
> > 
> > * the default screen # changes or even goes away completely; that could
> > render the selection manager useless. why is the CM atom per screen
> > again? *sigh*
> 
> Screen here is about traditional multi-head where you can have different
> window managers / compositing managers managing each screen.
> 
> > * 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
> > 
> > * 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.
> 
> I thought this bug was fixed, because I haven't seen it in a long time.
> But I realized that I still have a patch applied that I created a couple
> of years ago.
> 
> It adds a compositingChanged() signal to KWindowSystem and makes
> Plasma::Theme use it. It also uses Xfixes instead of KSelectionWatcher
> to monitor the selection.
> 
> I never committed the patch because Lubos didn't like the idea. IIRC the
> reason was that the signal would be emitted before the compositing
> plugins are initialized in kwin.
> 
> I have attached the diff in case it fixes the problem for those who are
> still seeing it.

Has this patch gone in?
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9