http://bugs.winehq.org/show_bug.cgi?id=20865
--- Comment #25 from Austin Lund austin.lund@gmail.com 2010-06-22 06:22:52 --- (In reply to comment #21)
There are cases where it's appropriate for a ConfigureNotify event to result in another ConfigureWindow request. Namely, if an application handles a WM_WINDOWPOSCHANGING event by supplying a new size/position.
But isn't the way to do the WM_WINDOWPOSCHANGING to adjust the WINDOWPOS passed in the lParam and not to call SetWindowPos()?
The one case I can think of where this makes sense is when a non-wine based movement of the window occurs. My guess is that either X or the window manager will do this and a ConfigureNotify event will occur because of it. But surely this is a reason to update the x11drv information (and send appropriate window messages) rather than calling SetWindowPos (unless you change the WINDOWPOS structure as above, which could be handled by checking if the WndProc did that).
The heart of the issue is when this occurs:
SetWindowPos(100,100,100,100) <- from application SetWindowPos(200,200,100,100) <- from application, no ConfigureNotify ConfigureNotify(100,100,100,100) <- from first call SetWindowPos(100,100,100,100) <- from wine ConfigureNotify handler ConfigureNotify(200,200,100,100) <- from second call SetWindowPos(200,200,100,100) #Two ConfigureNotifys are joined ConfigureNotify(200,200,100,100) #Done as things are consistent.
But this will make things jump around before being done. The issue is that SetWindowPos will return then another call to SetWindowPos can be made before the window is actually moved and the ConfigureNotify event is sent. If there was a lock which blocked the second SetWindowPos call until a configure notify event occurs between the first and second SetWindowPos calls then the jumping cannot occur. And if an external ConfigureWindow call happens then this is not blocked as it's only calling SetWindowPos that takes the lock and ConfigureNotify which releases it. If the external ConfigureWindow call occurs between the two SetWindowPos calls then it will jump around, but that would happen anyway.