[RFC] Enforcing Compositing
mgraesslin at kde.org
Mon Feb 21 20:47:14 CET 2011
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:
* 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
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 ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 316 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20110221/2009f0a9/attachment.sig
More information about the Plasma-devel