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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel