[RFC] Enforcing Compositing

[Thomas Lübking]

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

> If we know that R100 does not support it, we could use the GLPlatform to
w/o kms glxgears ran @200fps - that's not much, but might be enough. the  
problem seems that the driver only provides GL 1.2 for the GPU - whether  
for HW or SW limitations i didn't figure so far.

> detect it. Maybe find some sensible requirements? E.g. at least R300 or  
> NVIDIA 6xxx for OpenGL compositing?
nVidia GeForceFX does fine (have used it on a 5200FX - but you should not  
attempt to run google earth on top of it ;-)

> A plasmoid not in the default is as hidden as the button and I don't  
> think it's something for a default panel.
yes. or the cashew? (dunno)

> we know if we are a netbook, so we could change that.
does this mean "through solid" or "because plasma-netbook is running" -  
latter is not the same as "is a netbook"...

> 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)
It could however turn out tricky in implementation.
Either we keep properties on clients - killing central user control or we  
have a central root property and to rely on "clients don't f*** around  
with the counter" (which will probably be necessary so exiting one blocker  
will not resume compositing while others are up)
I'd prefer the central solution, since it provides an "easy" and WM  
agnostic final control for the user.

> I would like to have this work mostly automatically and our last attempt  
> just failed ;-)
Since there's a gap between the XRender and OpenGL features, the user  
should at least know (the "effect loading failed and kwin doesn't say why"  
bugreport)

> Maybe we could do something like trying to use OpenGL - if it works we  
> assume that TFP works.
If GLX_EXT_texture_from_pixmap is promoted and does not work, that's a bug  
in the GL driver. The user should face the problem, report a bug and get  
the hint to select XRender until the driver is fixed.
If GLX_EXT_texture_from_pixmap is NOT promoted and we strike shm, GL  
compositing is not supported and we should suggest to use XRender.
I think the biggest problem with the former fallback was that it happened  
under the hood and users wondered why things didn't work or sometimes were  
fast and sometimes not.
Ie. we need (in case of failure) a guided setup, not heuristic self-fixing.

> I will spend some thinking on it as I would like to automaticallybe able  
> to select EGL backend if possible (GLX just sucks).
Since we should know whether EGL is supported at all we can select it  
(though i wonder how distros are gonna handle this: kde-workspace-gles ./.  
kde-workspace-glx? eeww...)

Cheers,
Thomas