http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #33 from Austin Lund austin.lund@gmail.com 2010-06-24 06:29:55 --- I'll try and summarise what I got out of the conversation on IRC today.
The window can either be moved by wine or something external.
Currently moving the window by wine using SetWindowPos will calculate what needs to be done then store this position in the winex11.drv data structure and then sync with the X server by at some time calling XReconfigureWMWindow.
If an external move occurs, then a ConfigureNotify message is received and this needs to be passed to winex11.drv which at the moment is done by calling SetWindowPos.
Unfortunately this bug is a nasty side effect of this. If two SetWindowPos calls are performed before a ConfigureNotify event is received then the value of the ConfigureNotify coords will not match that in winex11.drv and will issue a SetWindowPos as if the window was moved from an external source. This causes the backwards moving events reported in this bug.
After a long discussion on IRC, I think I gathered that ConfigureNotify really never needs to call XReconfigureWMWindow to actually move a window. But it does need to call SetWindowPos to ensure that winex11.drv knows that a window move occurred (otherwise dependent windows will not be moved appropriately). At the moment to two things are bound together.
If there were two ways of calling SetWindowPos, the normal way and one which would do everything except call XReconfigureWMWindow then this would be enough. The ConfigureNotify handler would call the version which didn't issue a XReconfigureWMWindow. The downside to this is that the messages sent to WndProc would be doubled in most cases (i.e. WM_WINDOWPOSCHANGING and WM_WINDOWPOSCHANGED would be both sent twice, once from SetWindowPos and the other from the ConfigureNotify handler).