Version: (using KDE KDE 3.4.1) Installed from: SuSE RPMs When using window transparency with the x.org composite extension, new windows are sometimes rendered incomplete. for example, i press alt-f2 to get the "run command" box, and sometimes (with "sometimes" meaning "more than half of the number of tries") i get a window which is drawn incomplete (only the top left corner), but the shadow indicates how big it really should be. After moving the window, it appears in full. Another example is that sometimes a konqueror file manager window is resized, its drawn with invisible subwindows (or whatever i should call them) afterwards, the panel where the files are listed is invisible and sometimes the folder tree as well. moving it around doesnt help (as opposed to the partial popup problem), only another resizing. versions involved: x.org 6.8.1 on suse 9.2, kde 3.4.1 from suse, latest nvidia driver (happened with several different nvidia versions).
yet another occurence of the same "doesnt redraw properly" problem: maximize a window. sometimes, only a section in the top left corner with the size of the unmaximized window is drawn. and another: close a maximized app. sometimes, the underlying app window is not redrawn, but has the content of the closed window. when you force a redraw in any of those two cases, the "broken" window is ok.
seems to be related (or even a duplicate) of http://bugs.kde.org/show_bug.cgi?id=99832 at least, switching to a window decoration from the list mentioned in that bugs comments goes well as a workaround so far. too bad that all of the decorations mentioned in that list are (in my opinion) not as nice as plastik (or rather, smooth blend which is a modified plastik).
this is fixed in svn trunk (since short after 3.4 freeze) but wasn't backported to 3.4
so which version will have the fixes? 3.4.2? 3.5? 4.0?
afaik trunk will end up in kde3.5 (or 4.0 if there's no 3.5 :) so the patch will apply there if not backported
any chance to get it backported into 3.4.2 which is due in ... 3 weeks?
don't ask me - i'm not backporting anything here and i don't know about the backporting policy and process Hey Lubos (or anyone else?): read this? could you please answer him?
On Wednesday 06 of July 2005 19:20, Thomas LXXbking wrote: [bugs.kde.org quoted mail] Trunk will become 3.5. The backporting policy is roughly that no new features in general should be backported, and fixes should be only backported when they're deemed to be safe. Given that kompmgr itself is considered experimental I don't think there should be a problem with backporting there. The backporting process is that you check out the relevant branch (svn.kde.org/home/kde/branches/KDE/3.4/kdebase/... etc), do the changes there, check they're ok and commit.
ok, than the problem is that the fix (as the problem) happened somewhere on the kwin code (calling doShape() vs. resize) and at least plastik(!) code had some trouble about this (afaik that was for a plastik specific feature and a design issue, so sandro and me fixed that as well, but in trunk) so there may be side effects on this if only this is fixed in kwin. for self compilers it's however easy to fix, just swapped two lines (resize deco before the window itself)
This bug has reappeared in KDE4 svn. Tested on Intel GM965 and mach64 with XRender.
Since compositing code in KDE4 is a new codebase, please create a new bugreport about the issue.