Bug 192807 - Plastik window decoration doesn't paint for very small windows
Summary: Plastik window decoration doesn't paint for very small windows
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: decorations (show other bugs)
Version: unspecified
Platform: Fedora RPMs Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-15 19:14 UTC by Clemens Eisserer
Modified: 2013-01-30 16:21 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
screenshot illustrating the artifact (9.80 KB, image/png)
2009-05-15 19:15 UTC, Clemens Eisserer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Clemens Eisserer 2009-05-15 19:14:14 UTC
Version:            (using KDE 4.2.2)
OS:                Linux
Installed from:    Fedora RPMs

When using the plastik window decoration, for very small windows some parts of the decoration are simply not painted.

The window in the screenshot has been minimized and restored.
Comment 1 Clemens Eisserer 2009-05-15 19:15:10 UTC
Created attachment 33693 [details]
screenshot illustrating the artifact
Comment 2 Clemens Eisserer 2009-06-17 16:42:41 UTC
still happens on KDE-4.2.90
Comment 3 Clemens Eisserer 2010-04-06 00:30:14 UTC
still here, now in 4.4.1

Overall 4.4 feels a lot more buggy, than 4.3 was :/
Comment 4 Hugo Pereira Da Costa 2010-04-06 00:39:49 UTC
mmm. isn't the statement "Overall 4.4 feels a lot more buggy, than 4.3 was" somewhat disconnected with this bug report, since your comment #2 explicitly state that the same issue was there for kde 4.2.90 (and I assume kde4.3) ? 

Feel free to post as many reports as there are new buggy things in kde4.4 ...

As for the bug itself, can you
- reproduce with other deco ?
- reproduce with/without compositing ?

(here I cannot reproduce with compositing on. I do have some artifacts with compositing off, but not the kind of artifacts you show in the screenshots, and finally, cannot reproduce with e.g. oxygen.)
Comment 5 Thomas Lübking 2010-04-06 00:56:47 UTC
the bug is there. it's the closebutton. it occasionally paints pixmap garbage (what can end up being transparent) and the reason is:
QLinearGradient outlineGradient(0, 0, 0, r.height());
...
QLinearGradient surfaceGradient(0, 0, 0, r.height());

what got broken since the indirect deco painting (misses an XPutImage, i don't know why)
when there're more buttons, the image is being put with the second and implicitly "fixes" the close button (if the area has a pending repaint, pending like on the server, not the deco painting redirection)

the only solution i know is to ensure the gradient is cached in a pixmap and 2 painting passes one the one that triggers the caching.
Comment 6 Clemens Eisserer 2010-06-05 22:57:57 UTC
still in 4.4.80
Comment 7 Clemens Eisserer 2010-10-24 02:17:33 UTC
still in 4.5.2 + qt-4.7
Comment 8 Martin Flöser 2013-01-30 16:21:05 UTC
Plastik has been re-implemented in 4.10 on top of Aurorae. Because of that I expect this bug to be fixed, if not it's not a bug in Plastik but a general one in Aurorae.