| Summary: | incomplete widget painting leaves blank top right rectangular area | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | squan |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Unspecified | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Konqueror screenshot of described problem
Konqueror screenshot of described problem #2 Screenshot of effect described in comment #3 Screenshot showing incomplete rendering in dolphin |
||
|
Description
squan
2009-06-16 20:58:25 UTC
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. |