[RFC] Enforcing Compositing

[Martin Gräßlin]

On Monday 21 February 2011 12:23:36 Sebastian Kügler wrote:
> 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>
Thanks all for the feedback, it helped a lot.

So what we see is that the majority fears future driver regressions which is 
completely out of our control. Because of that we cannot enforce compositing.

So I would propose the following action items:
* do not change GUI as a complete rework is required
* target new GUI for 4.8 (don't think it's possible to get it done for 4.7). 
Therefore collect also input from Usability team.
* adjust code to enforce compositing in master - disable this before beta 
tagging
* improve situation with X devs - in whatever possible way (input welcome)

Thanks all
Martin
> 
> 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,
-------------- 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/ac58e8bc/attachment.sig