[RFC] Enforcing Compositing
mgraesslin at kde.org
Sun Feb 20 15:38:22 CET 2011
On Sunday 20 February 2011 15:12:58 Rohan Prabhu wrote:
> Having compositing enabled by default is good. Not allowing the user
> to switch it off is bad. Here are a few reasons why I think so:
> 1. Support does not mean performance: even though on some systems
> there would be enough support to have OpenGL compositing, the system
> may not perform that well. The performance may be choppy, and might
> cause a systemic lag. And it's not always possible to have an
> algorithmically valid assessment of this performance.
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?
The second issue should be gone with modern drivers (>= 7.10) and modern
compositor (master). If you currently have performance issues, install mesa
7.10 and current master and try again ;-)
> I do understand
> that if compositing is enabled without any effects, it shouldn't
> consume a lot more resources,
Effects do not cause more resources - those are idle most of the time. If you
don't use present windows, it won't cause resources to be occupied.
> but for newer users or non-experienced
> users, it might be a little troubling.
> 2. Some applications have a problem with compositing. A very specific
> example would be Warcraft III using Wine. Whenever I alt+tab without
> compositing on, it works. With compositing on, when I alt-tab back,
> all I get is a black screen. So for quite a few games I have to switch
> off compositing and play. Another good example would be Quake where
> the performance is affected severely with compositing on.
see Thomas' mail to the performance with e.g. games and possible solutions
> 3. Some just dont like it: I dont like the transperencies of the
> plasma dashboard and the tooltip boxes. I just put up with it because
> i really think alt+tabbing is cool and i am too lazy to track down
> which effect causes the transperency.
"Don't like" is no valid argument ;-) And no effect is responsible for
transparency, that's built-in
> My point is, dont enforce anything on the user. If need be, make it
> default but allow the user to change it if he/she wishes.
> On 2/20/11, Martin Gräßlin <mgraesslin at kde.org> wrote:
> > Hi all,
> > sending this to both Plasma and KWin as the idea affects the complete
> > workspace.
> > Since 4.2 we have enabled OpenGL based compositing by default and I was
> > wondering if in 4.7 we should go the next step: disabling the possibility
> > to turn compositing off if supported.
> > With Mesa 7.10 it seems that the driver problems (Mesa 7.8) which hit us
> > in 4.5 are finally gone and our new compositor is performing much, much
> > better than the one we have in 4.6. This means from a performance
> > perspective I am optimistic that we can go such a way.
> > This would imply the following changes
> > * Remove the enable checkbox in the compositing KCM
> > * Remove the suspend/resume compositing button in the same KCM
> > * Remove the "functionality checks" - the heuristic is rather useless
> > anyway * Disable unredirect fullscreen windows by default
> > I would keep
> > * the shortcut to suspend compositing
> > * the dbus call to toggle compositing (might be useful for games and so
> > on)
> > I am unsure about keeping respect to the Compositing/Enabled config
> > option. I
> > would say we do not honor it in development mode, but honor it again in
> > the branch. This way users could still disable it if something goes bad.
> > For development it's better to have the option not honored to get bugs
> > reported ;-)
> > If compositing is not supported, it will not try to enable it, so no
> > problem for our old, old, old users. (Though I doubt Plasma is of any
> > use in a system
> > not supporting OpenGL).
> > What do you think about this idea?
> > Cheers
> > Martin
> kwin mailing list
> kwin at kde.org
-------------- 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/20110220/2c022b07/attachment-0001.sig
More information about the Plasma-devel