|Summary:||Plastik window decoration doesn't paint for very small windows|
|Product:||[Plasma] kwin||Reporter:||Clemens Eisserer <linuxhippy>|
|Component:||decorations||Assignee:||KWin default assignee <kwin-bugs-null>|
|Latest Commit:||Version Fixed In:|
|Attachments:||screenshot illustrating the artifact|
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.