Peter Dons Tychsen <donpe...@tdcadsl.dk> writes: >> So... i have investigated other ways of fixing this. Would you accept a >> patch that uses _NET_WM_MOVERESIZ to move the window? That might also >> fix the issue. That message requests the WM to move the window at not X. > > I have now tested with _NET_WM_MOVERESIZ & _NET_MOVERESIZE_WINDOW > No cigar. They still have the same problem. > > I have also discovered a major problem in the X11 driver which is > affecting this problem (winamp). The mouse code uses the relative > coordinates of the window and compares it to the cached value in > "whole_rect" and "client_rect". There are 2 problems here: > > 1) "whole_rect" and "client_rect" do not reflect the actual state of the > window, as X might not have processed the request yet. These values > should at least be updated on ConfigureNotify instead which signals that > X has completed (and accepted) the request. > > 2) Using the relative coordinates from X is not a good idea, as you do > not really know where the window is at that point. Instead the same > message also supplies a "x_root" and "y_root" value. I did an experiment > where i used these values instead of the other to calculate the mouse > coordinate. This had an amazing effect on the stability and the > smoothness when moving windows in e.g. Winamp. I did have problems with > the virtual desktop though, but that can probably be fixed. > > Apart from this i am not really sure where the is a "window_rect" and > "whole_rect" as they are both overwritten with the same value every time > X11DRV_WindowPosChanged() is called. > > As you did not like my initial attempt to fix the problem, please advise > which route you would approve of.
What you should do first is spend a lot more time studying the code, before deciding that it has "major problems" and needs major changes. It's a very sensitive area where the smallest change has big consequences, and you have to be sure to know what you are doing. -- Alexandre Julliard julli...@winehq.org