[PATCH] Animations enable/disable system wide
Aaron J. Seigo
aseigo at kde.org
Fri Feb 15 21:09:32 GMT 2008
On Friday 15 February 2008, Robert Knight wrote:
> Several comments:
> 1) This is implemented as a binary yes/no option. Will that be
> flexible enough?
> 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.
> 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
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
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...
Size: 194 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel