Comment 18 for bug 437378

(In reply to comment #3)
> is opened for 2 years. ;-)
out of personal curiosity: link?

> (using a gdk_move_resize), shoudln't the WM be aware that it's a move+resize,
> and not a move followed by a resize ? after all, the XWindowChanges attributes
> contain both the size and position changes.

Did i recently start talking greece?
I don't know what gdk_move_resize actually does (google doesn't know it bug in related cairo-dock bug reports...) or whether cairo-dock is a managed (request) or unmanged (notify) client, but
   KWin does NOT make two XMoveResizeWindow calls out of one configure request
if the value mask contains ((x||y)&&(w||h))

If there's something "wrong" it has to be in the compositor / the behaviour of the xcomposite/xdamage extension (see my former post) or in OpenGL

Now* i did** install*** cairo-dock, and: "surprise" - NOT using the GL mode doesn't expose this problem at all, while it /is/ present in the GL mode, whether kwin uses the gl or the xrender backend....
-> it's probably in the cairo GL backend and/or a conflict with Qt similar to the one you mentioned above(?)

Then i suspended kwin compositing and launched xcompmgr (on kwin) - the issue apepars w/ or w/o gl in the docker. The glmode however also triggers

error 9: BadDrawable (invalid Pixmap or Window parameter) request 157 minor 1 serial 35709
error 3: BadWindow (invalid Window parameter) request 20 minor 0 serial 35710
error 3: BadWindow (invalid Window parameter) request 15 minor 0 serial 35711

in xcompmgr

From that time on kwin crashed in XRenderCreatePicture oni the XRender backend :-\
i'm gonna decide whether to blame cairo or xcompmgr later on... ;-P

---
* (what a shame)
** (because feeling forced, for no other reason)
*** (i'd like to state that i do NOT believe in dockers, DO NOT USE DOCKERS! NONE! - cairo dock makes a nice appearance, doesn't carry in a complete gnome desktop, but DO NOT USE DOCKERS, NEVER! =)