[RFC] Enforcing Compositing

[Martin Gräßlin]

On Sunday 20 February 2011 18:18:41 Thomas Lübking wrote:
> 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.
that get's me to think: what is actually our minimum GL requirement? I would 
say that we should at least require 1.5 but what is our code's requirement? 
Anyone knows it or do we need to track down the code? ;-)
> 
> > 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 ;-)
I guess with old nvidia cards you easily hit the black window issue.
> 
> > 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"...
true that should be through solid.
> 
> > 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 am more for on client and the compositor keeps track of it. No reason to 
allow clients to f*** around with it (and no I don't trust those apps).
> 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)
The better solution would be to hide the effects which are not supported by 
the current profile.
> 
> > 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.
there is no shm in master any more :-) If tfp is not supported it has to be 
XRender as fallback.
> 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.
the problem was that we run into a race condition with all drivers except the 
NVIDIA blob.
> 
> > 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...)
no idea yet and probably off-topic to the thread. What I play around as an 
idea in my head is to compile all compositing parts twice and load the 
compositor as a plugin depending on EGL works or not. The test could be done 
by two out-of-process applications: one compiled against GLX (could be the 
same as the current direct rendering check app), one against EGL. What I'm 
afraid of is startup-time.

Cheers
Martin
-------------- 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/97269b04/attachment.sig