[RFC] Enforcing Compositing

[Martin Gräßlin]

On Monday 21 February 2011 20:25:23 todd rme wrote:
> On Mon, Feb 21, 2011 at 11:35 AM, Martin Gräßlin <mgraesslin at kde.org> wrote:
> > * improve situation with X devs - in whatever possible way (input
> > welcome)
> > 
> > Thanks all
> > Martin
> 
> If I am understanding what I am hearing correctly, kwin, gnome 3
> shell, unity, and to a lesser extent firefox are all doing basically
> the same thing, and are therefore going to run into the same problems.
>  If that is the case, what about doing one, or both, of these:
actually no, 
* Compiz is still mostly OpenGL 1.x code, even after the port to GLES, it's 
mostly wrapping the OpenGL 1.x code into a 2.x API.
* GNOME Shell is using Clutter, a scenegraph. That's like if we would try to 
build kwin on top Qt Components
* Firefox is doing WebGL, they expose the complete API of GLES to any 
application and are very concerned about stability (possible security 
vulnerabilities). KWin only uses a very small part of the GLES API.

The KWin code is closest to Compiz, especially as they at least wanted to 
reuse our GLES shaders. I have not yet looked at their implementation, but I 
really hope they are using them or that we can merge them.
> 
> 1. A joint meeting, or at least communication, involving these groups
> (and probably compiz as well)
btw Unity == Compiz
> to try to unify approaches, so everyone
> is doing more or less the same things in the same ways.
OpenGL is too complex for that. There are (to my knowledge) five different 
ways to specifiy geometries. KWin uses three of them (OpenGL 1, OpenGL 2 
without shaders, OpenGL 2 with shader) and at one place (logout effect) the 
forth one (which needs to be removed). If I get around to add OpenGL 3 support 
we will also use the fifth version (Geometry shaders).

OpenGL is also a state machine. It's really difficult to track the state 
correctly - that's why projects like Gallium have been started.

Trying to get our code in the same way is just impossible. Setting the states 
in a different order might change the world.

What we can do is reduce the API usage and that's what we did. One of the 
reasons why I started with GLES is to get the codebase to use only a subset of 
the API. Now with Compiz also porting to GLES and Firefox requiring GLES and 
Gallium3D providing a common state tracker there is the hope that GLES gets 
more pushed and improved.
>  That would
> mean that if there is a problem with xorg, it should effect everyone.
> 
> 2. Get together and communicate with xorg devs as a group, rather than
> isolated projects.  As I mentioned, problems with firefox seemed to
> get instant attention, while problems with KDE seemed to be ignored or
> blamed on KDE (even though they were the exact same problems).  So
> teaming up with developers who have more traction may get better
> results.
Mozilla is mostly concerned about stability and has raised some rather 
"strange" requests to mesa. Our implementations are so different that we 
cannot demand anything together except trying to beat on the devs, which I 
would not want to do ;-)

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/20110221/2009f0a9/attachment.sig