[RFC] Enforcing Compositing

[Sebastian Kügler]

Hey all,

<exec summary>
- let's try it in unreleased master for a bit
- let's see how Unity and GNOME shell are received
- let's try to improve communication with Xorg devs
- let's target it for 4.8
</exec summary>

On Sunday, February 20, 2011 15:38:22 Martin Gräßlin wrote:
> We have two categories of problems
> 1. Hardware not supporting OpenGL properly (e.g. Ati R100 in Thomas'
> example) 
> 2. Performance problems caused by bad implementation
> 
> For the first one, there is only one solution: Don't use Plasma. It does
> not  meet our hardware requirement. Windows 7 wouldn't run on it, Mac OS X
> would not run on it, GNOME Shell would not run on it, Unity would not run
> on it, why should Plasma still support legacy hardware?

While I sympathize with the "compositing only" idea, I've got a couple of 
concerns:

- What about remote clients? Will the just get a non-composited desktop?

- Some drivers support Compositing just fine, but make the machine feel laggy, 
we've had this problem with NVidia for quite some time, and I still sense it 
on my Intel w/ openSUSE 11.3 sometimes. Switching off compositing makes it 
faster

- Regressions: To users that don't have a good graphics driver and hw combo, 
it'll just look like a regression ("Plasma doesn't work anymore"), that's not 
what we should do to our users.

- Crap graphics drivers

In my humble opinion, it would be wrong to make this change for 4.7. Let's 
first get Unity and GNOME shell in the hands of the users, and try to find out 
if it's really not a problem, if it is, we'll save some users some grey hair, 
and we offer a real alternative to those burned by GNOME shell or Unity 
instead of repeating their mistakes. If it works out, nothing's lost when we 
go this route for 4.8 (other than keeping a UI option in there for one more 
cycle -- a small price to pay).
Instead of breaking existing users' setups (those with crap graphic drivers), 
let's for *once* not be the guys taking the beating by being among the first, 
let us support those that are not willing to go through any level of pain, and 
who don't care about compositing or not (those are quite a few is my 
experience).

Furthermore, I think the "let's just expose X driver problems, then they'll 
get fixed faster" is a bit too optimistic as long as we keep failing to 
structurally communicate with those (few left) driver developers. In reality, 
it takes too long to get an issue fixed, and that's partly our fault. The 
solution here is not to enforce compositing, but to work on our communication 
with Xorg developers, and make it easy for them to straighten out the stack so 
KWin and Plasma run well. I've talked with some Xorg driver developers in the 
past months, and they're pretty much completely unaware of KWin's problems 
with compositing. They don't have the info about that available. We should 
probably not expect that driver developers test KWin. :/

Martin also offered the possibility to remove this feature in our development 
version for a while, and see what happens. I think it would be wrong to switch 
of back on only after branching, but "breaking" it for two months should be 
fine, and offer plenty of feedback.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9