John Woodhouse posted on Thu, 28 Apr 2011 15:23:35 -0700 as excerpted:
> /strong></div><div><br></div><div>
Please don't post in HTML to the mailing lists. Many users choose not to
enable html parsing (or use clients without the option at all) for
security or other reasons. You may be able to see some of the resulting
mess above and below, depending on how well your client cleans up broken
html. Since the set of users likely to have the knowledge to answer
questions and the set of "traditional" users who tend to view HTML
formatted posts with suspicion intersect rather heavily, it's probably not
a good idea to risk offending them with posts they consider security risks
if HTML were to be allowed, but simply an ugly mess since they don't. =:^(
> I was running an older nvdia 7600
> graphics card and it struggled with the desktop effects. The default os
> nv driver doesn't fully exploit this
> card.</div><div><br></div><div>
More HTML junk...
Ehh... the nv driver is deprecated. nouveau's the replacement, and in
fact for aging nVidia cards, now generally matches or exceeds the
servantware nvidia driver's performance, according to recent tests by
phoronix. But it does appear that you mention the nouveau driver below...
> About time I upgraded the card so fitted
> a 210 silent. On the nouveau driver it's ok but window
> movement was somewhat jerky to start off with but has settled down now.
> Auto timing changes? - KDE decided to disable effects on the 7600
> within an hour of me using it.</div><div><br></div><div>
More html junk...
> The glxgear
> performance with the correct nvidia driver for the 210 is about 4x
> faster than with nouveau. Full 1680x1060 res gives 200 frames per sec.
> Nouveau is so slow it's very jerky. On 32bit with the nvidia driver I
> also saw the slow desktop fade in. Currently with the nouveau driver
> and the 210 that doesn't happen but windows do go
> transparent.</div><div><br></div><div>;)
More html junk...
> I sort of like the effects but to me they mean that os drivers are a no
> no if they are to be enjoyed.</div><div><br></div><div>
... And even more html junk...
FWIW, I purchased a Radeon (hd4650 FWIW) precisely because AMD /does/
cooperate with the community and there are reasonable freedomware drivers.
Of course, I couldn't run the servantware drivers if I wanted, because as
with most code (including freedomware), there's a disclaimer of liability
should the code turn out to damage the hardware or whatever. But how can
I reasonably be expected to take responsibility for black-box code I can
neither examine myself, nor have someone I trust examine for me (in the
case of someone who can't read the sources themselves)?
I'd argue that I cannot reasonably do so. Thus, I won't waive the
author's/supplier's responsibilities and take them on myself, and they in
turn don't give me a license to run the code. As such, at least here in
the US, there's a very real legal possibility I do not have the legal
right to run nearly all servantware code, even should I want to do so.
(And on the basis of that argument, I'd argue that nullifying such damage
waivers for providers who refuse to open their code, would nicely solve
the problem. There are a few providers who *DO* take such liabilities for
the code they ship -- in airplanes and nuclear reactors and the like --
but the cost is *FAR* from trivial to do so. Thus, invalidating such
damages waivers on code that the user isn't as equally free to inspect as
they are expected to agree to such waivers... would solve the problem, by
forcing black-box suppliers to charge prices to cover the liabilities
they're not allowed to require users to assume since the users can't see
what they're assuming. That would effectively price black-box solutions
out of the market for all but the most high-priced solutions, leaving the
consumer software market pretty much 100% freedomware.)
Anyway... before my upgrade to the radeon hd4650, I was running an old
radeon 9200. But I refused to turn off effects like window translucency
that I already knew could work perfectly well on the hardware, because
they'd worked perfectly well on kde3. As a result, I learned how to
select specific effects, turning off others I didn't want/need, and to
tweak the ones I had on to work acceptably fast.
The big trick is setting animation speed. This setting is found on the
general tab under Desktop Effects and defaults to "normal". By setting it
to "very fast" or even "instant", effects such as transparency fade-in
that are otherwise unworkably sloooowwww become far more usable. =:^)
(Conversely, those with fast graphics and systems may want to set this to
slow, very slow, or extremely slow, to get the full effect of transitions
that would otherwise be so rapid they'd hardly see them. On my new Radeon
hd4650, I have it set to slow.)
There are a few other similar tricks as well. One is choosing (and
configuring) the effects you want individually, on the All Effects tab,
rather than by group, on the general tab. In general, effects triggered
only rarely and only on demand (desktop switching, shutdown, etc) can be
enabled more liberally than those triggered frequently (window fade-in/
fade-out, especially when switching windows, etc). Here, I really use
window translucency, but not shadows, so shadows are disabled, for
instance. And the desktop grid is only triggered on demand and can be
impressive and fun even if it's a bit slow, so as long as it works at all,
it might be worth enabling. (Note that desktop cube animation is a
totalling different effect, designed to be triggered on routine desktop
switching; I do NOT have it enabled.)
A second is the configuration for window translucency, which allows
setting the fading duration speed for it alone, separate from the default
settings on the general tab. I actually found this setting before the one
on the general tab (I'm not sure if the one on the general tab even
existed in kde 4.2.4, when I first switched from 3.5.10) and played around
with it a bit. I discovered that on my old hardware, even the lowest
arrow-selectable 100 ms was WAY too slow -- as if the setting were
designed for 100 ms total but was actually doing 100 ms per frame, several
SECONDS total! But I could type in a much smaller value, and I found
something on the order of 2-10 ms worked pretty well. 0 ms was no
transition, just active to inactive in one shot, for instance. I believe
that's what the "instant" option on the general tab does too (or default
here, when the general tab setting is instant), but I liked a /bit/ of
transition, it just had to be MUCH faster than even the lowest 100 ms
spinner value, 2-10 ms instead of 100, so 10-50 times faster than even the
fastest spinner value setting.
A third minor trick is setting the effect and duration of the virtual
desktop switch, as found in Workspace Behavior, Virtual Desktops,
Switching tab.
A fourth minor trick applies not to kwin's effects, which the above
control, but rather, to plasma's effects, set entirely separately. This
is set under Application Appearance, Style, on the Fine Tuning tab. Set
the Graphical Effects dropdown to one of the low CPU options.
Another one, should be a relatively minor effect now but due to a bug, it
had a MAJOR effect in 4.2 and IIRC early 4.3, has to do with activity/
desktop plasmoid/widget placement when window translucency is enabled. In
general, on a slow machine, you don't want high-update-frequency widgets
being redrawn on layers behind the top window. This is most critical for
the desktop, which is always behind any windows drawn on top of it.
Therefore, if you use window transparency at all on a slow-graphics
machine, only put static or low-frequency update applets like weather and
the comic-strip plasmoid on the desktop. Keep high-frequency update
plasmoids such as system monitors on panels set to auto-hide or always-on-
top, NOT windows-can-cover or windows-go-below. This way, they'll always
be the top thing shown and won't affect compositing performance like they
can if their frequent updates are composited thru several semi-transparent
windows. (The bug in early kde4, or more accurately, in early qt4 and the
way it interacted with early kde4, caused the entire desktop to be
repainted with each of these updates instead of just the small normally
rectangular area affected by the update. That was just too much to be
workable on slow graphics systems. Along about kde 4.3.something or
possibly 4.4.something, IDR exactly, they caught this drag on performance
and coded things to avoid it. Later, qt changes made it more difficult to
trigger in the first place. Both of these caused the update to trigger
repaints in only the relatively small affected area, generally that of the
plasmoid itself, not the entire desktop, so now the effect will be far
less of a problem than it was back then, but it could still make some
difference on slower hardware.)
> It's nice to see that 4.6.0 is relatively stable so far.
That it is. =:^) (Only it's was, for me, as 4.6.2 introduced a
regression, tho I've temporarily fixed it by replacing the particular
library in question with the early 4.6.0 version, after which 4.6.2 has
been fine for me as well.)
This is where I'd normally put the bit about upgrading to the latest kde,
now 4.6.2, since thru 4.5, each upgrade, both the minor/feature upgrades
(4.4 to 4.5 for example) and the micro/bugfix upgrades (4.5.4. to 4.5.5
for example), had enough bug fixes and improved functionality that it was
worth the upgrade. However, 4.5 finally reached what I'd call reasonable
x.0 quality, what /should/ have been 4.0, and other than the fact that 4.6
drops the hal dependency, it isn't that big of a deal. Further, counter
to the previous trend, both the 4.6 micro-updates so far have had notable
regressions from 4.6.0. So I've been recommending that folks who are on
4.5 or previous and are comfortable with hal for the time being, upgrade
to 4.5.5 and stay there, while those who are already on 4.6 or who really
need to get rid of the hal dependency that 4.5 and previous had, go with
4.6.0, and stay there for the time being. Of course, for most, this will
be to some extent decided by their distribution's upgrade timing and
policy, but even so, many can add package repositories with the upgrades
if they wish, and of course, kde can be compiled from sources as well if
desired.
So yeah, I'd say stick with 4.6.0 for the time being, seeing as you're
already on 4.6.0 and find it relatively stable. Hopefully by 4.6.4 or
4.6.5, the regressions affecting 4.6.1 and 4.6.2 will be worked out and
what remains will be an even better 4.6, but that remains to be seen.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
