Video upload not possible, so I put the screencast on YouTube: http://www.youtube.com/watch?v=JqUVFrRSfWA

Which was your previous KDE version? Did you update anything besides KDE, such as some component from the graphics stack (mesa, libdrm, xorg)?

I upgraded from KDE 4.3.x to 4.5.5 to 4.6 Beta RC2. I also dist-upgraded from Kubuntu 10.04 to Kubuntu 10.10. I'm pretty sure that within this dist-upgrade some graphics stack packages were upgraded, too.

can you please activate the "show paint" plugin, trigger such issue and check whether the dirty area is excluded from the repaint?
do you have other windows on other virtual desktops which cover the dirty area?

Hi Thomas, I created a screencast with the show paint plugin enabled, you can find it on YouTube:

http://www.youtube.com/watch?v=7SdcmSF97QY

I'm not sure if I understand what you mean by "other windows on other virtual desktops which cover the dirty area"…?

And another one showing Kate editor here:

http://www.youtube.com/watch?v=yQmUMRCHjkc

I have 4 virtual desktops, Kontact is running maximized on #4. Please let me know if and how I can provide you with additional info!

there seem to be insufficient damage events - i assume you're NOT using a git (development) version of XOrg? (there's been recently a change about damage event queuing)

a) are only KDE/Qt applications affected?
   a1) iff - does switching the UI style have any impact?
b) Do you use the blur or sharpen filter?
    b1) are they the culprits?
c) does it happen with both backends (OpenGL/XRender, "kcmshell4 kwincompositing", "advanced" tab)
d) do you use kms?
   d1) does swapping ("nomodeset" at grub, in doubt: google) help?

Created attachment 56574 [details]
KWin showing a partially updated window

I think I'm affected by the same bug or a similar one. If that's the case, I think I could have additional information.

I have two Kubuntu installations. Both were freshly installed from a Kubuntu 10.10 CD so there shouldn't be any lingering configuration from previous versions.

I use one of the installations as my regular desktop. The other is for "experiments" and more cutting-edge stuff. Right now, both are almost identical, just upgraded to KDE SC 4.6.0 but in the latter I've also installed the closed source ATI Radeon driver (fglrx).

With the closed source driver everything works as expected. However, with the open source ATI driver (package xserver-xorg-video-radeon 1:6.13.1-1) I suffer from the window contents updates described in this bug. This bug begun manifesting with KDE SC 4.6.0, the previous version worked just fine.

I've done some tests and the problem only occurs with desktop effects activated. It affects several applications, most notably (for me) Chromium browser, but also happens in Firefox and the desktop in general. In fact, it's happening as I write this (some keystrokes doesn't seem to produce text and then everything I typed suddenly appears).

I managed to capture a screenshot of this problem but it's quite difficult to do for me because is quite unpredictable.

If I can help by providing additional information please tell me so.

a) No, it also affects Eclipse IDE (Java)
b) Yes, I use blur filter. However, I disabled it and restartet KDE, yet no improvements
c) It seems like only OpenGL makes this issue happen. Using XRender, some desktop effects are disabled, but repainting works properlya) No, it also affects Eclipse IDE (Java)
d) Yes I do. With kms disabled (passing modeset=0 to the i915 module as mentioned in [1]) X/kdm and graphical bootsplash doesn't work anymore

[1] https://wiki.ubuntu.com/X/KernelModeSetting

Created attachment 56578 [details]
Kwin configuration file

This is my current Kwin configuration

I can confirm these strange and annoying problems. 

My configuration: 
Kubuntu 10.10 with KDE 4.6.0
Xorg 1.9.0, Intel GM965.

When desktop effects are enables some repaint/update problems start happening.
These also include:
- jitter in text rendering or editing with kate and other programs. Very annoying and compromising usability!
- broken text/images when scrolling
- Gwenview freezing with half-loaded images
- problems/jitter using Firefox web-browser
- Slow update of console (Yakuake)

None of these problems happened with KDE 4.5.x, even if some issued with scrolling/text editing could be experienced with Gtk-based applications (like firefox).

With KDE 4.6 also Qt-based apps are affected and Gtk apps seem to suffer even more.

I'm currently using OpenGL rendering with pixmap method and direct rendering.

from comments #9 (not in fglrx) & #10 (not in xrender) this seems to be in mesa, however:

- do you use vsync'ing?
- please disable /all/ effects but keep compositing active (no need to restart kwin, in doubt toggle compositing with shift+alt+f12)

The use of vsync seems to solve the problem.

I will test the system a little longer to make sure it's not just a temporary improvement.

you mean /activating/ vsync "fixes" it?

what if you raise the fps rate (default is 60, >999 is capped anyway):
kwriteconfig --file kwinrc --group Compositing -key MaxFPS 999

the weird thing is that the unsynced fps limiter should hit xrender as well...

Sorry if I was not clear: the problem seems to be fixed (or at least greatly reduced) when VSync is active.

I tried to raise the FPS to 999 as you suggested and when
VSync is active -> Problem does not show up
VSync is not active -> Problem shows up
both at 60 and 999 fps.

I must add that even with Vsync enabled there are still some very minor issues (like kate's sub-menus flickering, not showing up at first click or just showing gray background and no text) but major problems seem to disappear.

No, you were clear enough - i had just rather expected the opposite =)

What if you lower the framerate to eg. 30fps (check with showfps whether it really applied, you have to suspend/resume compositing after setting the value)
Notice that sync'd painting will raise the fps to the next multiple of your monitor refreshtime.

In my machine I get similar results after some preliminary tests. With VSync enabled, the problem is greatly minimized. I managed to trigger some partial updates but they are pretty rare now.

Do you want me to do the same tests changing the FPS values?

yes please, we should know whether increasing or decreasing the fps can cause dropping of damage events (even if it's in mesa/the driver)

Ok, I've got some "interesting" results.

First, I tried setting MaxFPS to 60 and 999 and got the same behaviour as Tomasso: the problem persists. It's as bad as it was initially.

I'm afraid that Setting MaxFPS to 30 doesn't make a difference. Same frequent partial updates.

However, during these tests I enabled the "Show FPS" effect to verify that the setting was being honored and, strangely enough, the problem doesn't show up that way! With Show FPS enabled I couldn't trigger the bug. It was perfect.

Another strange behaviour I notice is that setting MaxFPS to 999 and enabling Show FPS made KWin consume a lot of CPU (and boy, the scale effect was really smooth!) but with Show FPS disabled the CPU consumption was more or less normal. I wonder if in the latter case the FPS were really as high.

By the way, to back your theory of mesa as the culprit I can confirm that in my computer at work, which uses the proprietary Nvidia driver, KWin works as expected. There are no partial updates there.

Is there anything else I can do to help you?

I confirm all Alvaro's results. 
FPS settings seem to be honored.

I was not able to trigger the problem when ShowFPS is enabled. If ShowFPS is disabled the problem happens again.

I experienced the CPU usage increase when the FPSmeter is shown (to ~35% when fps=60 to ~90% when fps = 100).

At the moment I'm also getting some minor troubles with the cursor not being redrawn correctly (getting stuck somewhere, having different cursors displayed at the same time) even when if Vsync is enabled. It just happens inside this rekonq's textbox. I could not trigger this problem neither in kate nor in Firefox (which usually is more affected, being GTK based). 

By the way, my complete configuration: 
Kernel 2.6.35_x64, Xorg 1.9.0, MESA 7.9-devel (the one in Ubuntu right now), Intel driver 2.12.

the observed fps counter behaviour is normal - it repaints the entire screen continuously as fast as possible (what causes the cpu load)

however the fact that it "fixes" the bug has to mean that the damagerect (hint of the "to update" area) is not present (or complete) when the damageevent is send.

what if you switch to indirect rendering:
    export LIBGL_ALWAYS_INDIRECT=1
before starting KDE (if your ~/.xprofile is not auto-interpreted, hook it into the autostarts - there's a gui for this in "systemsettings" )

Perfect! With LIBGL_ALWAYS_INDIRECT=1, no VSync and no MaxFPS the problem is gone. At least, I couldn't trigger it with my personal tests.

I'm going to keep using that option so I'll tell you if I find any problem.

I know this is not part of the bug fixing process but I'm curious: what does indirect rendering mean?

Not perfect :-(

With indirect rendering the client (in this case probably kwin, do you run any other opengl based clients? cairo-dock or so?) doesn't access the GL hardware directly but through the X11 server.
This has a major advantage if you're operating on a distant machine, since X can schedule paintings etc. to lower bandwidth but also has some overhead (ie, direct rendering is faster)

We've however had a *lot* of trouble with mesa/opensource GL drivers and direct rendering in the past (from crashes to freezes, so your experience is actually an "advance") - so you've likely been using indirect rendering in the past for some blacklist or failed test and no used direct rendering - so nothing would be lost.

In the long run you however should use direct rendering. Also v'syncing is NOT possible with indirect rendering at all (not matter what you check in the config dialog - it's simply not supported) as well as probably some effects or the lanczos filter (i think glsl does not work w/o dri, but am not really sure about this)

Oh, sorry to hear that. Let's fix it then! :-)

Thanks for your explanation. Now I understand what's indirect rendering and why isn't the solution.

I'm not sure if I really was using indirect rendering before. I can't confirm it because I'm not at home right now but when I activated inidirect rendering a minor problem I was suffering since KDE SC 4.5 at least (that is, before partial updates appered) has also been "fixed". The slight fade out effect when logging out (whe KDE asks if you really want to restart or power off) always had glitches. To give you an idea, it was like grabbing the current image, stretching it, displacing it and superimposing it with a slight transparency over the fade out effect. As I said, I need to confirm it later but I'd say that this glitch was also gone with indirect rendering. Wouldn't the fact that I was experiencing it before KDE SC 4.6 mean that indirect rendering *wasn't* active then?

Is there anything I can try to help you find the bug?

If you compile from sources you could try to re-activate the XSync based paint defer.
it 's around composite.cpp:416

#if 0
    // skip windows that are not yet ready for being painted
    ToplevelList tmp = windows;
    windows.clear();
    // There is a bug somewhere that prevents this from working properly (#160393), but additionally
    // this cannot be used so carelessly - needs protections against broken clients, the window
    // should not get focus before it's displayed, handle unredirected windows properly and so on.
    foreach( Toplevel* c, tmp )
        if( c->readyForPainting())
            windows.append( c );
#endif

it has been disabled for bug #160393 but the XSync protocol implementation was broken before 4.6 anyway (and actually doing it (hopefully) right now might cause this bug)

Oh, I work in Computer Science so I'm not afraid of compiling stuff but I've never compiled KDE myself so I'll probably need some hand holding and patience. Also, it'll probably take some time to do it.

Nevertheless, I always wanted to compile KDE myself so this is a good reason to finally do it. :-)

Good news! I managed to compile KDE from sources. There were some bumps along the road but in the end it was much easier than I expected. KDE truly rocks!

And more good news: uncomenting that piece of code really works! I did these experiments in my aditional Kubuntu installation, after uninstalling fglrx. Now I get partial updates with my regular user and the "old" KDE, but there are no problems (so far) using the build with your patch (with another user). And I guess it's not using indirect rendering because the artifacts when logging out are still present.

I suspected sth. lie this (i suspect it to be responsive for another issue as well) if you can, leave it enabled and use this version of kwin, watching for errors that seem introduced by this code (as described in bug #160393) so we can ultimately reactivate the code (maybe opt-in for testing purposes)

Well, now something strange happened.

Just to be sure, I reverted composite.cpp and recompiled (I ran cmakekde without "cleaning" first) but now I can't trigger partial updates with this KWin! Supposedly, it has to be just like KWin as provided by Kubuntu packages, and I still has the partial updates problem when running regular KDE with my normal user.

I guess I should erase everything and recompile from scratch but I'd say that KWin was updated after I reverted the file so I'm not sure why this is working. Any advice?

I'll try to recompile everything tomorrow if I have time.

a) sure that LIBGL_ALWAYS_INDIRECT is NOT ser in the surprisingly working
environment?

b) could be a downstream bug (ie. kubutu patched "stuff" in)

c) could be a compiler optimization thing (eg. you compiled as debug while
kubuntu cmpiled as -O3, ie. heavy optimization) - you'll /have/ to mimic
kubuntus compiler settings to rule this out, but before ask whether and what
they patched into kwin code.

I'm rebuilding from Ubuntu's source package, using Ubunu's dpkg tool... I'll let you know what happens as soon as I'm finished. 
I just upgraded the intel xorg driver, so I first want to test it alone...

*** Bug 265133 has been marked as a duplicate of this bug. ***

From my first test I could not notice any improvement with the patched Ubuntu source, I'll try with a "vanilla" KDE source.

I finally compiled KDE from Ubuntu sources (apt-get source -b kdebase-workspace) with the XSync based paint defer activated (I deleted the #if 0...#endif) and I can confirm Tommaso's results: the problem persists.

Also, I've been investigating and I'm afraid I made some mistakes. It really seems that I had been using XRender with my development user.


This is the output of "kwin --replace" in my normal user (both vanilla KWin and Ubuntu's KWin):

OpenGL vendor string:                   Advanced Micro Devices, Inc.
OpenGL renderer string:                 Mesa DRI R600 (RV770 9442) 20090101  TCL DRI2
OpenGL version string:                  2.1 Mesa 7.9-devel
OpenGL shading language version string: 1.20
Driver:                                 R600C
GPU class:                              R700
OpenGL version:                         2.1
GLSL version:                           1.20
Mesa version:                           7.9
X server version:                       1.9
Linux kernel version:                   2.6.35
Direct rendering:                       yes
Requires strict binding:                no
GLSL shaders:                           yes
Texture NPOT support:                   yes


And this is the output with my development user (Ubuntu's KWin):

OpenGL vendor string:                   Advanced Micro Devices, Inc.
OpenGL renderer string:                 Mesa DRI R600 (RV770 9442) 20090101  TCL DRI2
OpenGL version string:                  2.1 Mesa 7.9-devel
OpenGL shading language version string: 1.20
Driver:                                 R600C
GPU class:                              R700
OpenGL version:                         2.1
GLSL version:                           1.20
Mesa version:                           7.9
X server version:                       1.9
Linux kernel version:                   2.6.35
Direct rendering:                       yes
Requires strict binding:                no
GLSL shaders:                           yes
Texture NPOT support:                   yes
kwin(8822) KWin::Workspace::setupCompositing: KWin has detected that your OpenGL library is unsafe to use, falling back to XRender. 
kwin(8822): Failed to initialize compositing, compositing disabled 
kwin(8822): Consult http://techbase.kde.org/Projects/KWin/4.0-release-notes#Setting_up 

(With vanilla KWin it changes to:

Direct rendering:                       no
Requires strict binding:                no
GLSL shaders:                           no)

In fact, using KDiff3 I can confirm that there are no differences in KWin between vanilla and Ubuntu sources.

I don't know why I can't activate direct rendering with my development user but the fact is that, unfortunately, the XSync based paint defer doesn't resolve the problem. Sorry for misleading you.

Is there anything else that I could try?

Any updates with this bug? I'm still willing to cooperate to try to squash it. Is there anything I can do?

This is probably not a bug in KWIn but in the GL driver / Mesa (see comment #9, it's never ben on nvidia css either) - have you tried 7.10?

I now switched to Arch Linux and I'm currently running mesa 7.10 and intel driver 2.14. The problem seems to be fixed.

Seems to be a driver bug. Please update to latest drivers if you experience the problem

*** Bug 268731 has been marked as a duplicate of this bug. ***

So how do I as a regular user resolve this bug?
I'm experiencing it on two computers on work - both intel.

You should try to upgrade your MESA to version 7.10 and intel driver to version 2.14. Not sure which one of the two packages is responsible for the error, but I guess MESA is the culprit. You can try to fetch the new version from backports repo or try to compile it yourself. Please refer to your distro's documentation or forum.

As a last resort (but very easy to apply) you could try creating a file in .kde/env with:

export LIBGL_ALWAYS_INDIRECT=1

It's just a workaround but it could be enough until your distro updates MESA or the drivers.

@alvaro: sounds very easy. What is the cost?

@Pascal: According to comment #24 it seems that indirect rendering (that's what you get with that setting) is not as efficient as the default direct rendering. Anyway, I use it at home and I haven't notice any perceivable effect.

If you're going to try it, I think the file contents should really be:

#!/bin/bash
export LIBGL_ALWAYS_INDIRECT=1

I think the file doesn't have to be executable but giving it that permission won't hurt.

Good luck!

*** Bug 268997 has been marked as a duplicate of this bug. ***

Good news. After upgrading Kubuntu to 11.04 (Natty) the problem is gone. It seems the driver was indeed the culprit.

That maybe just because intel removed the GEM string from their driver ID and thus DRI isn't activated anyway.
a) does blurring work?
b) if you run "kwin --replace &" from konsole, what does it say about direct rendering
c) does it still work if you run "KWIN_DIRECT_GL=1 kwin –replace &" instead (enforce direct rendering)

a) Yes. What's more, blurring never worked with the open source drivers before (in Ubuntu 10.10).

b) This is the output:

OpenGL renderer string:                 Gallium 0.4 on AMD RV770
OpenGL version string:                  2.1 Mesa 7.10.2
OpenGL shading language version string: 1.20
Driver:                                 R600G
GPU class:                              R700
OpenGL version:                         2.1
GLSL version:                           1.20
Mesa version:                           7.10.2
X server version:                       1.10.1
Linux kernel version:                   2.6.38
Direct rendering:                       yes
Requires strict binding:                yes
GLSL shaders:                           yes
Texture NPOT support:                   yes

c) This is the output:

OpenGL renderer string:                 Gallium 0.4 on AMD RV770
OpenGL version string:                  2.1 Mesa 7.10.2
OpenGL shading language version string: 1.20
Driver:                                 R600G
GPU class:                              R700
OpenGL version:                         2.1
GLSL version:                           1.20
Mesa version:                           7.10.2
X server version:                       1.10.1
Linux kernel version:                   2.6.38
Direct rendering:                       yes
Requires strict binding:                yes
GLSL shaders:                           yes
Texture NPOT support:                   yes


In all cases, I can't trigger the bug.

> OpenGL renderer string:                 Gallium 0.4 on AMD RV770
Sorry, i thought you'd be on an intel chip - just forget what i said in #48 then. Doesn't affect you at all.