Unless there is a specification saying that our behavior is wrong, I do 
consider our behavior as valid and don't want to fix what is not broken.

Especially Cairo dock is known for compatibility issues and is not a common 
application under Plasma.

The claimed assumption that kwin would set size and position independently if there's a combined configure request is (afaics) wrong, the geometry update is blocked in the configure request until everything's done (position/size/contrainment)

There /might/ rather be a relation to the "dirty texture" issue, however as Martin pointed we've had former reports on "cairodock + qt + opengl = weird issues", therefore 

@Cédric
you should figure whether it does also happen with the xrender backend.

"Cairo dock is known for compatibility issues"
if you mean the issue that makes all applications having embedded video invisible when the dock is running, that has been proved to be a bug in Qt and is opened for 2 years. ;-)

apart from that, the dock runs fine in KDE (it just lacks a plug-in to access the KDE's VFS), except the flickering. When a window is configured by the app, (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.
Currently, it seems that either 
 - the dock's window is redrawn by the WM at its new position before it's resized
 - or (more likely) the WM uses the old window's content to draw the newly resized window.
So you see the window at a wrong position for a short time.

The correct way would be to receive 1 configure event so that the app knows its new size and content, and then 1 expose event so that the app redraws itself, and the WM should not redraw the window with the old content until this is done.

Do you think something like this can be achieved ? or do you see any workaround that could be implemented at the app level ?
Because anyway as it is right now, it can be considered as a bug.

(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! =)

"KWin does NOT make two XMoveResizeWindow calls out of one configure request"
that's what I wanted to be sure.
so there shouldn't be any problem with it the move_resize* (as we have with Metacity).

Now about this bug, it appears that I misunderstood the bug reported by Cedric. It's actually a miscalculation in the position of the icons when one of them is being removed (there is an animation, the icon's size decreases to 0, and in some occasion the calculation is wrong). I'm surprised you didn't notice it in cairo-mode, but as this bug occurs in certain conditions, it's probably just a coincidence.
It's of course independant of the WM, and is different from the flickering I was thinking about (wrong refresh of the window during a move_resize, which is very brief).
So I apologize for taking your time, it's a wrong alert. ^^

About the bug in Qt, it's a serious one, and here is the link (please note that VLC and VirtualBox have included a (dirty) workaround to avoid Qt using an alpha channel in their visual). You can find bug reports here: http://bugreports.qt.nokia.com/browse/QTBUG-5464
http://bugreports.qt.nokia.com/browse/QTBUG-12315
http://bugreports.qt.nokia.com/browse/QTBUG-15092

although it (and its workaround) is very well known, they have just ignored the problem so far...

thanks for your concern and your reactivity !

PS: the KDE panel IS a dock ;-) if panel is for you a dock that doesn't move, then Cairo-Dock can also act like a panel.

* gdk_move_resize is a mere wrapper around XMoveResize.

(In reply to comment #5)
> cairo-mode, but as this bug occurs in certain conditions, it's probably just a
> coincidence.
Framerate/Sync issue?

> So I apologize for taking your time, it's a wrong alert. ^^
Nevermind, since it lead to a fix anyway, it was no waste =)
 
> About the bug in Qt, it's a serious one
Thanks for the links, i can however
a) not confirm the issue (though also style side ARGB + embeds now work here, X11 thing?)
b) not suggest using XLIB_SKIP_ARGB_VISUALS as a general hack because it will invalidate translucent windows (like cairo-dock, plasma etc.)

What troubles me is that cairo dock than apparently triggerd ARGB windows for Qt clients? Makes no sense (but to late to investgate now ;-)

> PS: the KDE panel IS a dock ;-) if panel is for you a dock that doesn't move,
> then Cairo-Dock can also act like a panel.

Ok, to be more precise:
"Don't use a docker to put starters or a traskbar into it, not in plasma, nor elsewhere" ;-)

VLC has included "XLIB_SKIP_ARGB_VISUALS=1" directly into their code (and I believe VirtualBox too), because this is the only way right now to prevent Qt from allocating an ARGB visual for a window.
although this can sound crazy, there is no other way (and yet, why the hell a video player would ever need a translucent video frame ?)

of course using XLIB_SKIP_ARGB_VISUALS must be done for each app specifically, not  for the session.
it's maybe an X problem, but then why only Qt-based video app ? Gtk windows with an ARGB visual + opengl work fine.

if you can't reproduce it (really ? starting cairo-dock in opengl mode and then opening Skype or Smplayer works ?), maybe there is some hope ^^

(In reply to comment #7)
> VLC has included "XLIB_SKIP_ARGB_VISUALS=1" directly into their code
unlikely (but for the embed) since i still can get the window translucent (bespin/qtcurve/oxygen support such)

> believe VirtualBox too), because this is the only way right now to prevent Qt
> from allocating an ARGB visual for a window.
The more driving question is why cairo/dock/gl causes Qt to do so, because it will trigger the "expensive" path in compositors, break shadows, etc.
This btw. is not changed back after shutting down cairo-dock, all new Qt clients allocate an ARGB window.
-> this should really be fixed/avoided or at least mentioned like "notice that using cairo-dock (in gl mode) will make Qt4 apps be slower" ;-P

> it's maybe an X problem, but then why only Qt-based video app?
> Gtk windows with an ARGB visual + opengl work fine.
Only embeds have been affected so far and afaics only xv embeds, the opengl sinks on smplayer et al. used to work even then. (at least that was the situation when intentionally allocating ARGB drawables)

... the reason seams to be that cairo(-dock?) feels like it has to set a custom color map on the root window

RGB_DEFAULT_MAP(RGB_COLOR_MAP):
                colormap id #: 0x1400001
                red-max: 255
                red-mult: 65536
                green-max: 255
                green-mult: 256
                blue-max: 255
                blue-mult: 1
                base-pixel: 0
                visual id #: 0x8c

calling "xprop -root -remove RGB_DEFAULT_MAP" sanitizes the Qt behaviour.

-> cairo(-dock?) bug. period. =P

that's an intersting clue, although I have never set a colormap on the root
window ^_^;
but it does on the dock's window.
maybe a bug in gtkgl ? by the way how do you know this is a custom color map
? and who set this ?

2011/1/6 Thomas Lübking <thomas.luebking@gmail.com>

> https://bugs.kde.org/show_bug.cgi?id=262064
>
>
>
>
>
> --- Comment #9 from Thomas Lübking <thomas luebking gmail com>  2011-01-06
> 17:52:40 ---
> ... the reason seams to be that cairo(-dock?) feels like it has to set a
> custom
> color map on the root window
>
> RGB_DEFAULT_MAP(RGB_COLOR_MAP):
>                colormap id #: 0x1400001
>                red-max: 255
>                red-mult: 65536
>                green-max: 255
>                green-mult: 256
>                blue-max: 255
>                blue-mult: 1
>                base-pixel: 0
>                visual id #: 0x8c
>
> calling "xprop -root -remove RGB_DEFAULT_MAP" sanitizes the Qt behaviour.
>
> -> cairo(-dock?) bug. period. =P
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>

(In reply to comment #10)
> I have never set a colormap on the root window ^_^;
you shouldn't anyway.

> but it does on the dock's window.
that would be the proper approach.

> maybe a bug in gtkgl?
maybe. in some base of cairo-dock for sure.

> by the way how do you know this is a custom color map? and who set this ?
Jedi abilities. I "sensed" it would be sth. like this...
ok, i just used my cheap & ordinary human brain.

"sth." in cairo-dock must change "sth." with global and persistant impact, "let's just check the root window... hmmmm, RGB_DEFAULT_MAP looks unfamiliar but i know that colormaps are related to ARGB windows - let's just remove it"
-> all new undecorated clients get shadowed again, therefore are not ARGB
-> that's it. Ensured the culprit by logging into a "failsafe" session, checked root properties (no colormap), launched cairo-dock (yes colormap), concluded:

YOUR FAULT ;-)

well you're more familiar with the dark side of X than me ^^
anyway it's not yet "my fault" ;-)
doing furher investigation, I've found that the colormap is set when I call the function gdk_x11_gl_config_new_from_visualid (which gets an opengl config from an ARGB visual, which is then used to give opengl abilities to the GTK windows of the dock).
I'm going to dig into gdkgl to see if I can undestand why it happens.

I still don't see why this should be a problem for Qt apps though (although I do agree that it sounds weird to change the root colormap).

thanks again for your help !

(In reply to comment #12)
> anyway it's not yet "my fault" ;-)
yes it is - you use the wrong toolkit ;-P

> I still don't see why this should be a problem for Qt apps though
X11 is "flat" ie, a "window" is actually only a random X drawable (window type) that's parented by the root window.
Back then, this was no different from the root window children internal structure (ie, "every button was an own X11 drawable" (this has been changed for poor performance on esp. local session)
In other words (and shortened): all windows are part of one mega window (what effectively makes X11 MDI by design - ewww =) and every X drawable inherits settings of the root window - this includes the colormap.
Now, whether X11 or XEmbed are supposed to work across drawables with different colormaps or xv should support ARGB windows or if this is (has been) a bug in Qt, X11 or the drivers - I frankly don't know. 
Maybe the Qt window constructor should just ignore/reset colormaps not explicitly set - I don't know either (in fact, I don't know a lot...)

However a client should just not change the "default" colormap, because several other clients may simply not expect this internally (gtk (1.x) -for one- didn't like that at all. Qt cannot apply stylesheets to at least the "window" in ARGB mode, what some applications might rely one, etc....)

Until you figured why gdk does so or gdk gets fixed, you could call

Display *dpy = XOpenDisplay (0);
XDeleteProperty ( dpy, RootWindow (dpy, DefaultScreen (dpy)), XInternAtom ( dpy, "RGB_DEFAULT_MAP", 0) ); // there're probably gdk hooks for the rootwindow/the display - use them.

afterwards - but that's oc only a workaround.

*** Bug 318800 has been marked as a duplicate of this bug. ***