hi!

In my setup shadows are drawn badly... I'd say they're almost invisible but in certain scenarios I can see they're drawn in an interlaced manner. Consider the following screenshots:

Chromium


KWin


I'd love to know why the shadows are drawn that way and whom to reach to discuss this issue - KDE developers or video driver developers?

This is ATI Xpress 1250 on-board video chip and xf86-video-ati 6.12.192-1 video driver.

The shadow code has not changed for quite some time and is working probably for most users and I have never seen such an issue. I'd blame the video driver.

mgraesslin wrote:The shadow code has not changed for quite some time and is working probably for most users and I have never seen such an issue. I'd blame the video driver.

Except for three things I've noticed with KDE 4.5's betas and RCs so far, I'd agree; however, those three things make such a supposition suspect.

1. When a KDE 4.5 build is installed on a production-based core (such as Kubuntu 10.04 or openSuSE 11.2), it is far slower than KDE 4.4.x (and that is especially true if the default window manager, notably Kwin, is used).

2. I specified a production-based core for a reason: in the case of the two Linux distributions I cited, full hardware acceleration for AMD GPUs (I have an AMD HD5450) is available for 11.2 and 10.04; however, 11.3-testing/openSuSE Factory does not have such an option for HD5xxx, and Kubuntu Maverick Meerkat, being only at alpha 2, has a driver of similar quality. By confining things to a production core, the playing field is level otherwise.

3. Merely by swapping a different window manager for Kwin (usually compiz 0.9, which both distributions offer as an option for KDE), KDE 4.5, and especially RC2, gets back most of the performance deficit compared to KDE 4.4.3 and 4.4.4. Such a comparison narrows the offending slow code down quite a bit; while apparently *some* of the lag is due to additional code in KDE 4.5 compared to 4.4.x; the rest of the lag is apparently due to Kwin.

So, at least in my humble opinion, KDE is to blame; however, it's primarily the Kwin team (since merely swapping window managers erases most of the desktop lag) that has the issues.

PGHammer wrote:So, at least in my humble opinion, KDE is to blame; however, it's primarily the Kwin team (since merely swapping window managers erases most of the desktop lag) that has the issues.

What are you trying to achieve? Two different threads in which you blame KWin. Do you try to get us do something by whining? There are many reasons why Compiz is faster and my primary goal for 4.6 is to get KWin on par. But reading comments like yours I am not motivated any more as it is fast enough for me

To your concerns: KDE 4.5 will be shipped with e.g. openSUSE 11.4 and Kubuntu 10.10. So yes it is OK to depend on drivers which are not yet available in current productive systems. And yes it's called a release candidate not a release and we are working on improving the performance till the release. Do you really think we would release something which has performance regressions for most users compared to the previous release?

@PGHammer: Have you tried disabling the blur effect?

mgraesslin wrote:

PGHammer wrote:So, at least in my humble opinion, KDE is to blame; however, it's primarily the Kwin team (since merely swapping window managers erases most of the desktop lag) that has the issues.

What are you trying to achieve? Two different threads in which you blame KWin. Do you try to get us do something by whining? There are many reasons why Compiz is faster and my primary goal for 4.6 is to get KWin on par. But reading comments like yours I am not motivated any more as it is fast enough for me

To your concerns: KDE 4.5 will be shipped with e.g. openSUSE 11.4 and Kubuntu 10.10. So yes it is OK to depend on drivers which are not yet available in current productive systems. And yes it's called a release candidate not a release and we are working on improving the performance till the release. Do you really think we would release something which has performance regressions for most users compared to the previous release?

The very reason why I specified a production-based system was to eliminate other variables (such as beta drivers, variations in Xorg, etc.) from the comparison. Apples to apples, as opposed to apples vs. oranges.

Kwin (as KDE's default compositing manager) should, by rights, be *at least* as fast as any alternative (such as compiz), if for no other reason than to assure its use as the default compositing manager.

Lastly, if Kwin suffers from regressions, it will very much detract from the attractiveness of upgrading to a newer version of KDE that requires a change in compositing manager. Kwin 4.5.60 does *not* suffer from the regression-related issues to the degree that 4.4.92 did; so, rest assured that those issues *are* being addressed.

A postscript - I actually keep blur enabled because it's a feature I use (fade-in/fade-out depends on blur, for example); therefore, disabling blur is not an option.

PGHammer wrote:Kwin (as KDE's default compositing manager) should, by rights, be *at least* as fast as any alternative (such as compiz), if for no other reason than to assure its use as the default compositing manager.

Well it isn't and it will take time to achieve the same level. Plain simple as driver vendors use Compiz as their regression tests and have optimized their drivers for years to achieve a better performance with Compiz. That has not yet happend for KWin as we provide Compositing by default only since one and a half year. There are also more important reasons to use KWin and not Compiz. Compositing is only one task. We also have to have a look on the feature base and stability and future direction. Compiz has unfortunately a history of too many forks to rely on it as a base for KDE. If Compiz works better for you, feel free to use it. That's totally fine and that's one of the reasons why we try to cooperate with Compiz developers as far as possible, so that all features for KWin/Plasma integration are also available in Compiz.

PGHammer wrote:Lastly, if Kwin suffers from regressions, it will very much detract from the attractiveness of upgrading to a newer version of KDE that requires a change in compositing manager. Kwin 4.5.60 does *not* suffer from the regression-related issues to the degree that 4.4.92 did; so, rest assured that those issues *are* being addressed.

The only difference between trunk and branch is that trunk already has the blacklist to disable blur and lanczos filter on buggy hardware. This will be backported to 4.5 shortly before release. So I assume that your experienced performance problems was caused by either Lanczos or blur and that this is now disabled.

PGHammer wrote:A postscript - I actually keep blur enabled because it's a feature I use (fade-in/fade-out depends on blur, for example); therefore, disabling blur is not an option.

Nothing depends on blur. Fade in/out does not or should not blur the background. Plasma uses a different set of backgrounds when blur is not available. And as said I assume that blur is disabled on trunk for you.