[RFC] Enforcing Compositing

Aaron J. Seigo aseigo at kde.org
Mon Feb 21 22:11:23 CET 2011

On Sunday, February 20, 2011, Martin Gräßlin wrote:
> What do you think about this idea?

first, thumbs up for daring to ask the Big Questions. it's something i 
appreciate in you as a developer :)

so ...personally, i'm ok with re-thinking the options in the kcm GUI, but i 
feel that it is a very bad time to try and make it depend on opengl with no 
way for the user to turn it off because:

* some of our larger deployments (edu, corp) rely on being able to turn such 
things off

* it's a unique feature over the others, who are making this move but mostly 
because they don't already have something that works

* our users will scream and it will cost us momre users; without real upside 
to this, it won't win us any users only lose some

* fwiw, depending on the phase of the moon the developers are living under, 
the intel driver still goes through it's ... moments of despair. if i hadn't 
been able to turn off effects in kwin, i'd have been in some very, very bad 
places over the last 2 years

if we didn't already have the code there which works, i'd consider this 
differently perhaps. i assume that's why gnome-shell and unity are as well: 
they are starting from scratch, how much manpower do they really have? for 
mac, it's much easier: they control the hardware and the drivers, too. (and 
don't have the same kinds of deployments to support that we do?)

but we have code that works. we have people using, even relying on, those code 
paths. for me, that makes it a "-1".

i think the day will come where we will be able to do this, but we're not 
there yet. legacy is a bitch, x.org is still a wanker more often than we want 
it to be (and replacements are not there yet, try as people might to make 
wayland sound like the messiah arrived in the flesh today), but that's our lot 
in life right now.

i think it would be a strategic and promotional error to make this change 
right now. even if i utterly hate having to manage multiple code paths in 
plasma :)

what might make for an interesting "could it be done?", and i don't know if it 
could be in kwin, is taking all the non-composited code and moving it out of 
kwin core as a compile time option. this would at least allow devices using 
kwin to avoid whatever code overhead would be incurred. i'd even go so far as 
to remove the auto-disable functionality in those cases, since the harware is 
100% known.

p.s. not on the kwin list, though perhaps i ought to be. please cc plasma-
devel if you reply :) cheers.

Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20110221/001d6aa6/attachment.sig 

More information about the Plasma-devel mailing list