Version: (using KDE 4.2.90) OS: Linux Installed from: Fedora RPMs When resizing windows plasma repaints the desktop background in a too lazy manner. It seems to repaint only when the mouse stops to move for a very short period of time. This is not because plasma/Xorg can't keep up with repainting or the system is too slow, it happens with both the intel driver (UXA) and vesa+shadowfb. Even when the average load is low during resizing the effect shows up. I've recorded a small video illustrating the problem: http://www.youtube.com/watch?v=zidsFSiQwh0 When resizing on top of an application (e.g. Dolphin) the problem doesn't show up.
What is your graphics card / drivers ? What is your Qt4 version ? I can't reproduce the bug here using: Qt: 4.5.1 (qt-copy 971295) KDE: 4.2.92 (KDE 4.2.92 (KDE 4.3 >= 20090617)) kdelibs svn rev. 984425 / kdebase svn rev. 984427 Intel GMA x3100 KMS+UXA (GEM) xf86-video-intel 2.7.1, intel-dri 7.4.2 xorg-server xorg-server 1.6.1.901 on ArchLinux i686 - Kernel 2.6.29.4 on a Dell Inspiron 1525 Section "Device" Identifier "Card0" Driver "intel" #i810 Card "Intel X3100" Option "DRI" "true" Option "Tiling" "false" Option "RenderAccel" "True" VideoRam 261120 EndSection
Sorry, my kernel version is 2.6.30 (fixes some UXA bugs)
can't confirm with nvidia binary drivers. looks more like a driver/xorg problem to me. mark as upstream?
I only experience this whithout composition manager (otherwise re-painting is handled by the composition manager anyway). It happens with Intel+UXA+KMS, Intel+EXA, Vesa+ShadowFB so I don't think its an xorg or driver problem. CPU useage is low when this orrucs, its not caused by the fact that xorg can't handle all the paint events. It looks like simply plasma re-paints too little.
this is throttled by how much graphics performance and cpu plasma has access to. it paints as soon as it gets expose events, but the time required to paints varies depending on your graphics system as well as what else plasma is doing at the time; e.g. if it's busy in a loop somewhere, you may experience small hickups in painting. the issue is made visible in part due to various drivers and performance with full screen argb windows, QGraphicsView performance and whatever plasma-desktop itself may be doing. it is not, however, a bug in the sense "something isn't painting often enough" or even something that can be fixed with a specific patch. we'll see a major boost in speed with QGraphicsView in 4.6, which will help, and as more drivers improve and plasma itself is also further optimized over time it will improve. but as this is a "optimize the system from the graphics stack up to plasma" it's not a useful report. we are aware of, and working on, optimization efforts, however.
As I said, it happens with various different drivers, and CPU load is low when it orrucs. So plasma not beeing able to repaint often enough is not the problem. The problem only orrcurs when I resize windows, moving windows is fine. However in both cases plasma has to repaint the desktop. When resizing windows, I can keep plasma for 500-800ms from repainting. So either plasma receives too little expose events (I don't think, because Dolphin in background doesn't show that behaviour), or plasma (or something on QT's repaint logic) tries to minimize the amount of repaints by "optimizing" the incoming events and this leads to such artifacts.
I took a video resizing Konsole in front of plasma and Dolphin: Plasma: http://www.youtube.com/watch?v=DKdg-qzaYyo Dolphin: http://www.youtube.com/watch?v=VBT-qUdNnYc Don't tell me this has anything to do with Xorg, its a bug in your event handling / repaint logic.
I still think it's a xorg problem. But as a test, can you launch plasmawallpaperviewer -p image , resize it fullscreen and test again? I really can't reproduce it.. on multiple computers
With "plasmawallpaperviewer -p image" I can't see the problem, it repaints as it should. However I don't see an image. Why do you think its an xorg problem? I would agree if the same would happen with e.g. Dolphin in background, or if it would happen with the intel driver but not the vesa one, but it seems really consistent. 2009/6/25, Beat Wolf <asraniel@fryx.ch>: > https://bugs.kde.org/show_bug.cgi?id=197505 > > > > > > --- Comment #8 from Beat Wolf <asraniel fryx ch> 2009-06-25 18:48:51 --- > I still think it's a xorg problem. > But as a test, can you launch plasmawallpaperviewer -p image , resize it > fullscreen and test again? I really can't reproduce it.. on multiple > computers > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug. >
pet peeve: wasting my time re-closing reports that people decide to re-open "just because".. my job is not to educate everyone about the internal technical details of every part of the platform. i don't have the TIME to do so. sometimes you just have to trust me, or rather, respect how i handle the reports lodged against the software i manage. now, running plasmawallpaperviewer is next to useless as a text case for this because: * it does not use an argb visual * it paints on a straight QWidget, not a QGraphicsScene * it is not marked as a Desktop window (though that probably doesn't matter in this case) * it certainly doesn't have widgets on it, meaning that there is no multi-layer painting happening
another thing which will slip into KDE-4.3. And you wonder people complain KDE4 is slow ;)
*** Bug 204519 has been marked as a duplicate of this bug. ***
could you please re-open this bug? The dup prooves users are annoyed - so regardless who's fault this is - it destroys KDE's desktop experience partly, and it should be resolved.
and still in 4.4.85 - seems some thing never get fixed
works perfectly here, so it's for sure not a kde or qt problem, but a x.org problem with whatever driver that you use. i'm using the nvidia driver and it's no problem, to get this fixed you need to open a bugreport in the x.org bugtracker.
this has nothing to do with whatever driver I use, and to be honest I don't see how you come to that conclusion - happens with the "radeon" driver as well as "vesa" or "intel". Please change status to unconfirmed again.
i come to that conclusion because it does not happen with the nvidia drivers. if it was a kde issue, the bug would happen with all drivers, not only a few of them. so since you used open source drivers, it's likely a bug of xorg in a part that the nvidia binary drivers don't use. i will test in a few days on the laptop of my gf that has a intel card, but i'm to 90% certain that it does not happen there.
The drivers don't have to do anything with the way expose events are sent to the client app (=plasma), and that would be the only thing that could be wrong on X' side. Strange - I just found out if I resize a KDE application, plasma repaints immediatly. Resizing gtk-demo on top of plasma leads to the artifact described.
Strange, the issue seems to be window-manager related. When running icewm instead of kwin, plasma-desktop repaints immediatly regardless of which application I resize.
reopening for now and reassigning to kwin. thanks for the further research
Please remember to reset the assignee to default when reassigning to kwin, so that the mails end up on kwin mailinglist :-) Now to the bug... I try to summarize: Plasma repaints too slow with KWin as window manager compared to icewm if compositing is disabled. Is that summary correct? If yes I think it's a wontfix. One of the advantages of compositing is that apps don't have to repaint when other windows are resizing. So using Compositing fixes the issue. I don't think anybody has the time to investigate bugs in the "legacy" parts. Additionally kwin provides several settings like showing window content while resizing. I assume that this option is set and I assume it will be much better when this option is disabled.
a) i cannot reproduce this at all b) if only plasma's affected (on a limited mount of systems) i'd rather not blame the WM (see e & f on contrasting icewm experience) c) you seem to use a folderview background? (might be an important detail) d) konsole is no gtk+ application, gtk-demo has a an unbelievably slow resize routine (compared to the simple content) e) not used icewm for ages. does it perform a solid resize? (or just an empty frame), however i /think/ kwin had (has) a hack mapping a resize window below the actual window (no idea what it was supposed to do, though) f) this /could/ be related to XSYNC (but actually i don't see why except "works with icewm") g) add Option "BackingStore" "true" to the device section of your xorg.conf (if you regularily don't use compositing)
@Martin: 1. The bug is not that plasma is repainting to slow, it doesn't repaint at all. As long as I continously resize gtk-demo, plasma won't repaint when running kwin, it repaints immediatly when running icewm. 2. I don't use composition because window resizing is even slower with kwin in composition mode. Running Windows-7 windows resize much smoother with their Aero whatever composition stuff. I know this is not a KDE problem, but as long as @Thomas: a. I'll record a video, to make it easier to reproduce for you. b. Only plasma is affected, I don't blame anybody. I just say it works with icewm and not with kwin. No idea why. c. Yes I use a FolderView background, but also happens with Desktop d. No matter how slow gtk-demo exposes, plasma-desktop doesn't repaint for seconds. Seems also to happen with konsole, however its a lot harder to trigger. e. Yes, icewm performs a solid resize f. I guess its related to XSync g. BackingStore is considered deprecated, Xorg devs advice not to use it at all.
i doubt i'll be able to reproduce it (i tried quite hard :-) the d) reply ("hard to trigger") would (imo and if it's not QGraphicsView) point to and regarding f) and for clarification: i wasn't talking about the X routine (XSync() call) but a protocol extension on client messages. in case you compile yourself you could set "#ifdef HAVE_XSYNC" in geometry.cpp:3292 to "#if 0" (no - i did not test under this condition ;-) i'm aware that the BackingStore makes few sense since most toolkits store themselves and composition does pretty much the same (in this regard) not heard "deprecated" so far though. nevertheless it might work around this problem. if you launch konsole (first instance, no other konsole must be running) while compositing you should get (or can force, see --help) and ARGB window. does it show the same issue (eg. when maximizing and resize gtk-demo above it)?
me too
you too what.. can't reproduce?
No, if I launch konsole with composition enabled, disable it and resize gtk-demo above it I don't see the effects I see with plasma-desktop - it repaints as expected immediatly. I'll give a build with XSYNC disabled a try soon.
> you too what.. can't reproduce? No I see the same thing
kwin is in no way responsible for repainting in the non composited case. No idea why it seems to be faster with icewm, but given the status of reproduction in this rather long bug report it could also be the phase of the moon. Sorry no dev seems to be able to reproduce and nobody is experiencing it.
Thomas was able to reproduce it.
(In reply to comment #31) > Thomas was able to reproduce it. (Thomas Dempton) However, i can (somehow) reproduce it - but with gtk+ and the (and only the) Orta theme. (Backing store isn't enabled) But also (just tested) it hits IceWM the very same way.... It's (here) a pure matter of the exposed client, ie. it does NOT matter what kind of window i (quickly) drag across it - makes me wonder whether (iff related) it's a matter the plasma theme... *shrug*
I've just tested, and I am no longer able to reproduce this problem with kde-4.5.5 - probably it was related to kwin's XSYNC fixes. Great! :) kwin now behaves like icewm when resizing konsole, triggering repaints of the plasma-desktop immediatly.
for the records: unless backported by distro, the XSYNC fix is NOT in 4.5.5 it would have been sth. else in this case.