[PATCH] Animations enable/disable system wide

[Aaron J. Seigo]

On Friday 15 February 2008, Robert Knight wrote:
> Hi,
>
> Several comments:
>
> 1)  This is implemented as a binary yes/no option.  Will that be
> flexible enough? 

probably not.

> Animations in a small area can be typically done 
> even on fairly slow machines. 

it's not just slow machines, of course, but also network sessions (see below 
for more on that)

> Animations over a large area (eg. those 
> done by KWin) really need hardware acceleration to work properly.

yes, but it can be tricky to work out when something is h/w accelerated. (see 
below for more on that too)

> 2)  I don't think the meaning of the checkbox text and tooltips is clear.

agreed

> The reason for this option to exist is to improve performance on
> machines with slower graphics.

to add some detail to this: graphics capabilities are affected by:

* the graphics hardware (usually older or just very cheap chipsets)
* the graphics driver being used (poorly written/supported drivers)
* if the session is being run remotely (e.g. thin client, VNC, NX, RDP, etc)

> An alternative approach might be to have a slider with a number of
> levels for the performance - with the simplest and least costly at the
> top and the most expensive at the bottom.  This approach was used in

i wonder how many users will actually have the knowledge to pick an 
appropriate setting. perhaps it would be better to simply provide a set of 
use cases in a drop down box, e.g.:

Optimize graphical effects for: [ Modern desktop / laptop system
			  [ Low performance system
			  [ Remote desktop or thin client
			  [ Mobile device

the exact entries are pulled out of my posterior as i was typing this, but i 
think giving the user a set of options that map to the actual use cases might 
be a lot easier to figure out.

> - Minimal use of complex static 2D (eg. gradients), no animations
> - Use of complex static 2D (eg. gradients), no animations

well, gradients are less of an issue than animations on thin client systems, 
but more of an issues on poorly supported hardware or where there are 
accessiblity conerns.

use of gradients is actually fairly orthogonal to animation, since you may be 
able to handle animations just fine but be using a low colour display. the 
operator may also have a vision problem that requires high contrast 
(something gradients are often used to avoid). in those cases, you don't want 
gradients and complex SVGs, but you do want to keep the anims.

> - As above, but with simple animations (ie. Qt's animations)
> - As above, but with more sophisticated 2D animations (eg. which is
> what your patch allows)

well, Qt's animations are really not more or less sophisticated than the 
animations this patch is designed to turn off. the Qt dock widget animations, 
for instance, are probably murder on thin client systems due to roundtrips. 
these two use cases can be probably be folded into one and we need to ensure 
we can turn these anims off via API call in Qt.

> - As above, but with animations requiring hardware acceleration

this can be tricky. XRender calls are hw accelerated on modern Intel chipsets 
with the current Intel drivers, but not on many other driver/chipset combos 
do this AFAIK.

outside of OpenGL (which AFAIK is relatively easy to tell programtically 
whether it's being handled in software or hardware), it can be considerably 
more difficult to know when something is hardware accelerated due to the 
variance between drivers, not to mention x.org acceleration architecture 
being used and the toolkit (and version of it) being used in the application 
(since different versions of different toolkits work better or worse with 
different accel systems). not a pretty sight =)

if there is an easy way to cut through that gordian knot, perhaps one of the 
people more knowledgeable of the details of X11 might fill us in, but afaik 
that's the current state of things.

also note that these settings should probably also have a modifier for when 
operating on (low?) battery power. now we're getting into power management, 
and the UI for that belongs elsewhere, but it should be possible to jack down 
the effects when i unplug my device or when my device starts running low on 
battery.

Rafael's patch is a step in the right direction at least ... and now it's easy 
to find what needs to get fixed if we modify this API via an lxr search ;)

-- 
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 Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080215/91a6915f/attachment.sig>