[RFC] Enforcing Compositing

[Martin Gräßlin]

On Sunday 20 February 2011 14:52:16 Thomas Lübking wrote:
> 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")
If we know that R100 does not support it, we could use the GLPlatform to 
detect it. Maybe find some sensible requirements? E.g. at least R300 or NVIDIA 
6xxx for OpenGL compositing?
> 
> > 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.
A plasmoid not in the default is as hidden as the button and I don't think 
it's something for a default panel.
> 
> > * 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.
we know if we are a netbook, so we could change that.
> 
> 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...
This blocking is a nice idea. It would allow to really trigger a suspend and 
not just unredirection and would also handle the hd case very well (yes I turn 
compositing off when watching hd)
> 
> > 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")
I would like to have this work mostly automatically and our last attempt just 
failed ;-) Maybe we could do something like trying to use OpenGL - if it works 
we assume that TFP works. I will spend some thinking on it as I would like to 
automatically be able to select EGL backend if possible (GLX just sucks).
> 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 ;-)
hehe :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20110220/48770563/attachment.sig