Version: (using KDE 4.2.90) Installed from: SuSE RPMs QWidget repaints are somehow broken: Often it shows a rectangular area int the right top of the widget where no or only rudimentary rendering takes place (i.e its mostly white). This happens in at least 3 apps: 1) In akregator and kmail if you open/expand a folder in the tree view (QListView) on the very left then in most cases this results in a white rectangle in the right top of the QListView area. When hovering over an invisible item in this area it gets painted. 2) In konqueror sometimes resizing and scrolling leaves areas at the right top of the drawing area where almost no rendering happens (except of thin lines and frames). It's interesting that this effect is sometimes very insistant and then may disappear on one and the same konqueror window without appearant reason.
Sounds like a KWin or driver problem, but you could show a screen shot to be sure. Can you state which graphics driver you use? Are desktop effects enabled?
Graphics driver is i855GM, desktop effects are disabled. Screenshot will follow as soon I can capture it. In konqueror the misbehaviour shows up in single windows (never in all). This indicates against a driver problem.
Created attachment 34805 [details] Konqueror screenshot of described problem Snapshotting the effects turns out to be difficult but that gave me some insight on what's going wrong: I think the cause is most probably in how Qt processes paint (resp. render) events. May be kwin is somehow involved. It seems that redrawing gets somehow interrupted for a mysterious reason and is suspended until e.g the window loses focus. Let me explain: Snapshotting was hindered by the fact that unrendered regions were rendered as soon as the window lost its focus. There are also cases where losing focus causes a unrendered region to _appear_ in the top left edge of a konqueror window, an example is shown in Screenshot 1. When scrolling this window the effect disappears, and which each focus change it reappears. But as soon as I opened a new tab (using Ctrl-D) the effect was no longer reproducable in the original browser tab.
Created attachment 34807 [details] Konqueror screenshot of described problem #2 At the same time having the problem described in comment #1 in another konqueror instance I have a different effect: If I try to scroll a page in the scrolling onlz happens in a small region of the window. Depending on the scrolling direction (up or down) that region is at the top or at the bottom of the window. This effect happens in _all_ tabs of that konqueror instance. The window gets rendered correctly if it loses focus. On subsequent scrolling rendering will be incomplete again. With the time delayed snapshotting feature of ksnapshot I could capture this problem, see Screenshot 2.
I cannot see the first image as it's corrupt or something but the second one looks to be a Konqueror bug as it only affects the page area. What does the KWin "show paint" effect display during these glitches?
Created attachment 34844 [details] Screenshot of effect described in comment #3 @Comment #5: Screenshot was corrupt indeed, replaced it. > looks to be a Konqueror bug as it only affects the page area. The konqueror effects are inside the page area, in case of akregator and kmail thay are inside I subwidget (QListView and QTable) > What does the KWin "show paint" effect display during these glitches? Pardon, what do you mean by that?
Created attachment 34846 [details] Screenshot showing incomplete rendering in dolphin New Screenshot shows that dolphin is also affected by incomplete rendering effects. In this case the effect shows on a QTable, hence the problem seems independent of the underlying widget class. Also in this case the effect disappears (i.e. rendering gets completed) if the dolphin window loses focus (sometimes with some <1s delay).
@lucas: i don't think he's running composite at all. @squan: if you activate composition (desktop effects) you can select a "show paint" plugin which is rather a debugging help and colorizes areas on every repaint - so you can (more or less) see what's painted when the whole thing looks rather like a pixmmap allocation strategy issue to me (happens exclusively on scrollareas, does it?) as you're using intel (and probably some ubuntu?) you'll have to go through the unhappy "intel exa vs. uxa & pixmap allocation strategy" trip, sorry :-( start here: https://wiki.ubuntu.com/X/Troubleshooting/IntelPerformance
@Thomas (#8) > (happens exclusively on scrollareas, does it? yes, scroll areas is what all concerned widgets have in common! > as you're using intel (and probably some ubuntu?) you'll have to go through intel yes, ubuntu no (i have SUSE factory running) So probably this has nothing to do with Qt/KDE and I got these effects due to Xorg or intel driver update. But it's puzzling how losing focus get's rendering straight again. So may be apps should drop focus after rendering scrollviews in case of Intel hardware to work around this :)
loosing focus == setting QPalette::Role to QPalette::Inactive -> global update is required. This is probably how Qt uses various X11 requests/flushes/syncs depending on it's own painting conditions/strategies. (we want to assume that the global update routine is pretty expensive and not what you want to do while scrolling...) Therefore it could also be a Qt problem (and intel implements stuff right, just very strict) but i have really no clue on this. As there are however various troubles regarding intels exa -> uxa movement and incomplete changes by some distributions (in particular ubuntu...) documented, i'd rather blame intel/distros in the first place.
If compositing is disabled then it's definitely not KWin.