[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: compositingActive not efficient on XRandR events
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2011-07-18 9:53:29
Message-ID: 4936785.UNZquuAc13 () freedom
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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*

* 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.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks

["signature.asc" (application/pgp-signature)]

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[prev in list] [next in list] [prev in thread] [next in thread]