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

List:       kwin
Subject:    Re: Compositing manager
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2006-07-14 21:10:10
Message-ID: 200607142310.10205.l.lunak () suse ! cz
[Download RAW message or body]

On Friday 14 July 2006 19:23, Matias Valdenegro T. wrote:
> El Friday, 14 de July de 2006 10:46, Lubos Lunak escribió:
> > - Code doing effects should work with all scenes, at least for simple
> > effects. Currently the code in effects.* get a transformation matrix and
> > opacity value, both of which it can modify. Making an effect that makes
> > the currently moved window transparent is very simple.
>
> I don't agree that Effects should work in all scenes, as OpenGL compositing
> is very different in implementation and capabilities as XRender compositing
> (See Shaders and GLSL).

 That comma wasn't supposed to be there in the first sentence. Simple effect 
should work in all scenes (and note that it's the would-be-nice category). 
About half of kompmgr's features can be expressed as "change opacity this way 
for this window", if it's possible to do simple changes just by modifying 
opacity and geometry then even everybody would be able to code their small 
silly effects plugin. Of course if the effect would be mapping the whole 
desktop to surface of a Bart Simpson-shaped figurine and rotate it then 
there's no way XRender can do that.

 And this is not a must have. Duplicating simple effects is no big deal.

> I think we should decide first if XRender should be supported by KWin's
> Compositor, as is badly accelerated by current X.org drivers, and OpenGL
> compositing is a lot faster and less limited.
>
> The only problem i see by dropping XRender and supporting only OpenGL
> compositing is the dependency on propietary drivers of video cards.

 And dependency on something like Xgl? Why would Compiz otherwise require it, 
after all. Moreover, in the worst case the XRender scene can be kept 
completely separate, rather limited in functionality, and as such relatively 
simple.

 On the other hand I though XRender sucks without proprietary drivers as well 
(and indeed it still sucks even with them).

> >  It kind of works for this simple case, but it's probably not good design
> > for anything better. I don't know how to e.g. add shadows, because
> > they're not transformations of the window but something added. As I said,
> > this code can be simply dumped if it's too bad. Compiz seems to work by
> > having a first pass that finds the final transformation and the second
> > pass of painting seems to be actually done by the effects as well. I
> > don't really understand that stuff.
>
> As i understand, shadows are just an image that gets composited along the
> window, producing a bigger image that gets composited to the desktop.

 Well yes. But with the current design created by me there's no way to do it.

>
> > - The plugins should do only effects and not add functionality like
> > Compiz plugins. I don't think exposing all KWin internals to plugins and
> > let them mess with it is a good idea.
>
> What would be the difference between effects and functionality?

 Effects just paint and nothing more. In Compiz the functionality of the core 
is rather limited and things like e.g. window placement or window movement 
done by user are handled by plugins, which do all this by directly using 
functionality of Compiz core. It's an interesting design in a way, but I 
don't think I want that in KWin. Taking care of KWin bugreport is not simple 
even without various 3rd party plugins messing with internals.

 So e.g. as already mentioned for Compose, I'd prefer the functionality of 
that handled by KWin core and only the actual painting be done by an effect.

> I'm very interested in hacking KWin Compositor, expect work from me as soon
> as i finish this semester (By end of the month) and i get a new video card
> (Crappy SIS 6326).

 Still school in July? Strange country :). Anyway, since first should come 
discussion of some sensible design it looks like end of the month could be a 
good time for starting hacking ;).

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak@suse.cz , l.lunak@kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/
_______________________________________________
Kwin mailing list
Kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin

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