[RFC] Enforcing Compositing

[Marco Martin]

On Monday 21 February 2011, 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>

i kept myself quite away from this but yeah, i agree with the 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?

if they are remote applications running on a local x server, compositing would 
depend from what is supported on the local x server (just not sure about argb 
windows, do they work over network?)

> - 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

yes, this is still an issue, ridiculous in 2011 but it's still there.
however, if -all- mayor desktops start to require this, something could be 
pushed enough to change 
 
> 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).

yes, i would let this for 4.8 as well.

> 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

again, too soon now, but in a year from now there could be no way to avoid of 
x problems getting exposed (if one doesn't want to use xvwm for ever ;)

> 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. :/

we for sure have to communicate more with them, it's true as well that testing 
their changes at least with major window managers (and no, doesn't matter if 
they don't normally use, or hate them) should be part of their job,really 
(really, it's easier for them getting our software than for us get peces of 
all the graphics hardware existing on earth)

i don't know how a better communication channel can be put up, i guess as 
usual it's a matter of resources, and with the complexity stuff reached 
lately, it's really starting to show and badly, but this is another whole new 
rant ;)


Cheers,
Marco Martin