[RFC] Enforcing Compositing

[Thomas Lübking]

Am 20.02.2011, 13:38 Uhr, schrieb Martin Gräßlin <mgraesslin at kde.org>:

> With Mesa 7.10 it seems that the driver problems (Mesa 7.8) which hit us  
> in
> 4.5 are finally gone and our new compositor is performing much, much  
> better
> than the one we have in 4.6. This means from a performance perspective I  
> am optimistic that we can go such a way.

FYI:
I 've installed linux on an older notebook this WE and OpenGL on an R100  
chip with mesa 7.10 and xf86-ati turned out to be a bad joke - and i'm  
talking about glxgears @ 0.2 [sic!] fps here....
(good thing is that i've now more insight on this and compassion with it's  
users..., but i didn't get GL compositing to run there at all ("black  
screen"), even w/o kms (what fixed glxgears) and neither compiz nor kwin -  
XRender works "ok")

> This would imply the following changes
> * Remove the enable checkbox in the compositing KCM
> * Remove the suspend/resume compositing button in the same KCM

Whatever we do, i do strongly recommend to unify this - currently there're  
seems some state invalidating conditions (i was about to start this today,  
so luckily i got your mail first and didn't waste any time)
However, some plasmoid would certainly be the better way to provide  
suspend/resume than some hidden button in some kcm.

> * Remove the "functionality checks" - the heuristic is rather useless  
> anyway
PRO - i turned it off immediately (since the system can hang for whatever  
reason, turning off compositing might not fix it at all and i think it  
caused me one of the invalid compositing states)

> * Disable unredirect fullscreen windows by default

con)
Beware HD video playback - every current intel chip based system out there  
(i don't know about state of ati acceleration on linux - at least not for  
an R100 ;-) will push this + TFP entirely to the CPU :s
To me the only justification to not unredirect FS windows seem special  
environments like netbooks, ie. this would be a distro thing.

pro)
However and with resp. to the present issues with screensavers and  
memcorruptions after resume from STR, we might actually better push a root  
window property spec to "block" compositing (i guess dbus won't become  
part of NETWM :-) - allowing clients to anytime hint: "i'm a resource  
intense fullscreen/fullstage client - make me go fast!"
Also there's a bug (in kwin?) if you suspend from an unredirected client -  
seems the server is and remains grabbed then...


> I am unsure about keeping respect to the Compositing/Enabled config  
> option. I would say we do not honor it in development mode, but honorit  
> again in the branch. This way users could still disable it if something 
> goes bad.
see above as well - if we allow to "block" compositing this way it would  
be sufficient to set this property before kwin starts up (and can be  
changed anytime later on. at least we should not have the separate  
suspended/disabled conditions)

> What do you think about this idea?
In general a big PRO - since the X11 backingstore seems to die (?!) and  
every system should be able to do at least XRender compositing (i've  
installed openbox+xcompmgr on a Mach64 chip - that's an 8MB "All-In-Wonder  
Pro" ;-) there's no point in assisting users to shoot themselves for  
assumed power saving etc.

We just should ensure
a) a sane downward staging
    GL fails (or is greylisted "slow") -> TELL the user & ASK to try  
XRender - yes i know that the fallback was removed for issues, but  
consider them gone if it happens explicitly (we don't have to use nerd  
terms like GL & XRender ;-)
    XRender fails -> say sorry and "suspend" it by default (TELL the user  
that and how to "re-try")
b) a scaling (standard defining!) way to define conditions for temp.  
suspension (ssaver, STR, games, video playback etc) - we might have a  
short talk to smplayer + vlc developers on why the FS video panels should  
preferably not be root children and a longer talk to wine developers ;-)

-- 
Cheers,
Thomas