[Bug 20865] New: Steam login window jumps around the screen when moved
http://bugs.winehq.org/show_bug.cgi?id=20865 Summary: Steam login window jumps around the screen when moved Product: Wine Version: 1.1.33 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: austin.lund(a)gmail.com When running steam in Wine, at login screen if you move the window around, it appears to jump across the screen in a jerky manner, especially if the cursor is moved quickly. A trace using WINEDEBUG='+tid,+event,+x11drv,+win,+relay' (attached) shows that sometimes the X11 driver is getting ConfigureNotify messages after the window has moved but they seem to contain the wrong values for the position on the window. Sometimes the window is moved by the ConfigureNotify handler back to where it was originally, just for Steam to move it again. It is possible to see this if you parse the log with: grep -E 'win:SetWindowPos|x11drv:sync_window_position|event:X11DRV_ConfigureNotify' -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #1 from Austin Lund <austin.lund(a)gmail.com> 2009-11-28 22:58:03 --- Created an attachment (id=24998) --> (http://bugs.winehq.org/attachment.cgi?id=24998) WINEDEBUG='+tid,+event,+x11drv,+win,+relay' log -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #2 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-11-29 23:38:23 --- What Window Manager are you using? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #3 from Austin Lund <austin.lund(a)gmail.com> 2009-11-30 02:08:00 --- (In reply to comment #2)
What Window Manager are you using?
metacity -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #4 from Austin Lund <austin.lund(a)gmail.com> 2009-12-01 06:20:03 --- Created an attachment (id=25032) --> (http://bugs.winehq.org/attachment.cgi?id=25032) Test program showing bug This simple test program also shows the bug. In particular setting WINEDEBUG=+win and grepping for SetWindowPos (and the word "after") shows calls to SetWindowPos and some are in reverse order. The reversed ones also have different flags set. Interestingly, when I increase the timer interval, eventually it goes away. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #5 from Austin Lund <austin.lund(a)gmail.com> 2009-12-08 17:57:38 --- Well, I cannot recreate this on another system with 1.1.34 and different hardware (but OS wise, identical). Perhaps it is a bug in the X driver for my graphics card? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #6 from Austin Lund <austin.lund(a)gmail.com> 2009-12-08 18:02:12 --- Wait. Spoke too soon. It seems that on the other (newer) hardware, it just happens much less often. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #7 from Austin Lund <austin.lund(a)gmail.com> 2009-12-08 22:06:28 --- After a bit of playing around, I can recreate this by running a few 'cat /dev/zero > /dev/null' then running wine and the test program. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #8 from Vincent Povirk <madewokherd(a)gmail.com> 2009-12-14 00:41:57 --- I wasn't on #wine-devel when you asked about this so I'll have to settle for writing what I know or can easily look up on the bug. :( Wine's windowing system is odd in that it's controlled by two different servers: X and the wineserver. The position stored in wineserver is what programs see, and SetWindowPos actually updates BOTH positions (see set_window_pos and X11DRV_WindowPosChanged). As you may have noticed, the ConfigureNotify event calls SetWindowPos (see the X11DRV_ConfigureNotify function). Now, here's the fun part. We get a ConfigureNotify event every time the window moves, no matter who caused it. We ignore those events if the position we get matches the wineserver position. And here's the really fun part. If we are behind in processing ConfigureNotify events, we may get a notify event for a PREVIOUS position, causing us to move the window BACK to that position. If we get two ConfigureNotify events in a row, for the same window, we will discard the old one (see merge_events), but that is no guarantee that the event we are processing is the most recent. Unfortunately, I don't think there's any way to tell whether an event is due to Wine's configure request or something else. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 Vincent Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #9 from Vincent Povirk <madewokherd(a)gmail.com> 2009-12-14 00:45:26 --- Whoops, sorry, the decision of whether to move the window on a ConfigureNotify is based on x11drv's stored position for the window, not the wineserver position. Still, that doesn't change the rest of the analysis. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #10 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-12-14 06:27:36 --- I'm just curious, does the hack attached to the bug 9802 help? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #11 from Austin Lund <austin.lund(a)gmail.com> 2009-12-14 22:30:42 --- (In reply to comment #10)
I'm just curious, does the hack attached to the bug 9802 help?
I just tried it and it does not help. Exactly the same behaviour with the patch. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 Daniel Stiefe1maier <caliga(a)arcor.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |caliga(a)arcor.de --- Comment #12 from Daniel Stiefe1maier <caliga(a)arcor.de> 2010-02-19 11:42:04 --- TeamViewer 5 is affected by the same problem in at least two ways: a) The connection window that shows your partner's desktop, is resized a few times directly after creation. Sometimes it then stays at a wrong size (about 100x50 pixel, which is rather silly...) b) Widgets. (Select 'Chat' or 'Conference call' from the audio/video menu for example) They don't have a 'native' window title bar and use SetWindowPos when dragged. On my system, they jump arround like crazy. Things to increase probability of unwanted behaviour: - stress (like cat /dev/zero > /dev/null) - having compositing enabled (and some crazy compositing-toys - allow window manager to control the window (winecfg) On KDE at least, allowing the window manager to control the window leads to more WM_SIZE messages, when the connection window is initially created and resized. Is that because of what Vincent explained, or is it an additional KDE oddity? I'll try the patch from bug 9802 next week and report... So, in general, all applications that often do SetWindowPos in a short time, are affected by this problem. Suggestion: Would it be possible to have a list with pending ConfigureNotify events? (Or more exactly: a list of coords, for which we did configure requests, but did not receive ConfigureNotify events so far) Then it should be possible to distinguish between Wine's own configure requests and others!? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #13 from Vincent Povirk <madewokherd(a)gmail.com> 2010-02-19 12:44:32 --- There's no guarantee that the window manager will respond to all or any of our configure requests, and they're free to give a different size or location than what we ask for. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 Vincent Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |winex11.drv --- Comment #14 from Vincent Povirk <madewokherd(a)gmail.com> 2010-06-05 12:15:39 --- If we could defer ConfigureNotify processing until we know the window manager has processed any configure requests we've made, that would probably solve this bug. However, the X protocol gives us no way to figure that out. If we could send some sort of request to the window manager that we can be sure it will respond to, we could do that after making any configure requests. When we get the reply, we'd know the window manager has processed the configure request. We could abuse _NET_REQUEST_FRAME_EXTENTS for this purpose, if the window manager supports it. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 Alexey Loukianov <mooroon2(a)mail.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 --- Comment #15 from Alexey Loukianov <mooroon2(a)mail.ru> 2010-06-17 03:55:29 --- *** This bug has been confirmed by popular vote. *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 Alexey Loukianov <mooroon2(a)mail.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mooroon2(a)mail.ru --- Comment #16 from Alexey Loukianov <mooroon2(a)mail.ru> 2010-06-17 04:09:23 --- Still happens with the "New UI" version of Steam + wine-1.2-rc3. The bug behavior had slightly changed: now the window don't "jump" during the move itself, but it jumps in the same direction it was moved for about twice the distance of the original move. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 Colin Wetherbee <cww(a)denterprises.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cww(a)denterprises.org --- Comment #17 from Colin Wetherbee <cww(a)denterprises.org> 2010-06-20 02:38:39 --- (In reply to comment #16)
Still happens with the "New UI" version of Steam + wine-1.2-rc3.
And wine-1.2-rc4.
The bug behavior had slightly changed: now the window don't "jump" during the move itself, but it jumps in the same direction it was moved for about twice the distance of the original move.
I am seeing this behavior, too... not just for the Steam login window, but for all Steam windows. It happens on about 70% of the attempts for me. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #18 from Austin Lund <austin.lund(a)gmail.com> 2010-06-21 19:43:28 --- What I don't get is why SetWindowPos needs to be called twice. From what I can gather in the code, it goes something like this: Call to SetWindowPos() wineserver set_window_pos request is sent and updates x11drv position request sent to X server to move window ConfigureNotify event received (asynchronously) SetWindowPos() called with XEvent window information If the X server's window position doesn't match that of the x11drv then clearly this will go back and forwards until they do agree. Why is there the need to recursively call SetWindowPos? Surely SetWindowPos should just set the x11drv position and then the driver just does it's thing. If the window manager doesn't like the new position then the driver should try it's best to fix things up and send WM_WINDOWPOSCHANGED, etc. if the size doesn't match what was requested. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #19 from Vincent Povirk <madewokherd(a)gmail.com> 2010-06-21 20:40:19 --- The message processing and wineserver calls reflect the way this works on Windows. Windows is synchronous. The Windows application needs to have immediate control over the window position. The WM_WINDOWPOSCHANGING and related messages must be processed BEFORE SetWindowPos returns. The new position is really determined by the arguments to WM_WINDOWPOSCHANGING when it returns. Thus, the program has complete and immediate control over its position. You can think of user32 and wineserver has having its own self-contained windowing system that correctly imitates the Windows windowing system. This is necessary for compatibility with Windows programs. X is completely different. In X, we ask the window manager for a new position, and it moves/resizes our window when it gets around to it. Or not. And not necessarily in the way we ask. We get a notification whenever the position changes, with no indication of the reason. X11DRV_WindowPosChanged and X11DRV_ConfigureNotify are the glue that connects the fully correct and synchronous wineserver windowing system to the asynchronous X windowing system. ConfigureNotify must call SetWindowPos when we get something not requested so that the application gets a WM_WINDOWPOSCHANGING message (which it can use to request a different position, in which case we SHOULD send another configure request) and so that the wineserver position can be updated. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #20 from Austin Lund <austin.lund(a)gmail.com> 2010-06-21 20:51:23 --- Still not sure I follow. I understand the synchronous-asynchronous issue. But why not have most of it "behind the scenes" so to say. For example, calling SetWindowPos just sets the x11drv position after sending the usual messages and sends the request to update the window position in the X server. When the ConfigureNotify event comes in it just compares with what the x11drv has and updates it as necessary sending appropriate messages to the WndProc as required instead of doing the full SetWindowPos which may put in another move request to the server. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #21 from Vincent Povirk <madewokherd(a)gmail.com> 2010-06-21 21:07:32 --- 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #22 from Vincent Povirk <madewokherd(a)gmail.com> 2010-06-21 21:30:40 --- Created an attachment (id=29062) --> (http://bugs.winehq.org/attachment.cgi?id=29062) patch: update the x11drv position from ConfigureNotify events Does this patch improve anything? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 Vincent Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #29062|0 |1 is obsolete| | --- Comment #23 from Vincent Povirk <madewokherd(a)gmail.com> 2010-06-21 21:46:39 --- (From update of attachment 29062) Never mind, this needs (still) more thought. I think the x11drv position of a window (which consists of window_rect, whole_rect, and client_rect) needs to be updated in the ConfigureNotify event AND X11DRV_WindowPosChanging needs to check whether it has changed, which doesn't seem to happen for non-decorated windows like the steam window. I think that if we check for changes based on our most recent idea of the X position of the window (either a ConfigureNotify event or a configure request), that will prevent us from making more requests from these intermediate ConfigureNotify events. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #24 from Alexey Loukianov <mooroon2(a)mail.ru> 2010-06-22 03:37:52 --- Correct me if I'm wrong: as this problem is mainly connected with the "X Window Manager <=> Wine <=> Wine App" interactions then the bug shouldn't happen when using wine's virtual desktop feature thus dropping the X Window manager out of the game? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #25 from Austin Lund <austin.lund(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #26 from Alexey Loukianov <mooroon2(a)mail.ru> 2010-06-22 07:08:37 --- I had tested the issue a little bit more and found another interesting thing: if I move any of the Steam windows by pressing Alt+Space on the keyboard and selecting "Move..." from the window system menu then no jumps does happen. Also there are no jumps if I move the windows using window manager keybinding to activate the "mousedrag window move" mode (defaults to pressing Alt on the kerboard and dragging a window with a mouse, but I had it set to use Win key as the toggling modifier). Looks like the trigger for this bug to happens with Steam is due to Steam uses undecorated windows and tries to manage the window moves itself. Don't know if this proves the discussion related to the causes of the bug or contradicts with them. Another thing I want to mention again is that now days there are no jumps _while_ moving the Steam window but there's one big jump just after the window had been moved and the left mouse button had been released. And it is typical for window to continue moving following the mouse cursor even some more time _after_ the mouse button had been released (looks like that "left_mouse_button_up" event gets somehow posponed in favour of "mouse_move" events). Sometimes this may last for several seconds if i continue to constantly move the mouse at a not-so-fast but constant speed. It seems that this "never-ending-move" lasts as long as mouse produce a "mouse_move" events being "inside" moved Steam window. Placing some window that takes a lot of resources to redraw under the moved window increases this effect even more: I've been able to get the window continue moving after the left mouse button release for about a minute by moving "Game properties" windows over the maximized main Steam window. Hope this will help to track the bug down. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #27 from Alexey Loukianov <mooroon2(a)mail.ru> 2010-06-22 07:14:53 --- And another finding: turning off the effect of showing the window contents while dragging in the window manager greatly reduces the probability of the "jump after the move" but don't fixes it completely. Also the behavior I had mentioned it the previous comment when a window continue to move after the mouse button release still takes place. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #28 from Vincent Povirk <madewokherd(a)gmail.com> 2010-06-22 09:12:09 --- It will probably still happen because ConfigureNotify events are still asynchronous and we process them the same way. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #29 from Alexandre Julliard <julliard(a)winehq.org> 2010-06-22 09:22:26 --- (In reply to comment #28)
It will probably still happen because ConfigureNotify events are still asynchronous and we process them the same way.
Actually we don't, there have been several fixes that should help, particularly 00b06dac85c096f20f7beed8898553166f07e6ad. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #30 from Austin Lund <austin.lund(a)gmail.com> 2010-06-22 17:49:13 --- (In reply to comment #26)
Looks like the trigger for this bug to happens with Steam is due to Steam uses undecorated windows and tries to manage the window moves itself. Don't know if this proves the discussion related to the causes of the bug or contradicts with them.
The test program which is attached does recreate how Steam's login window handles things. Note that what you are saying is exactly what happens. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #31 from Alexey Loukianov <mooroon2(a)mail.ru> 2010-06-22 17:51:42 --- (In reply to comment #30)
The test program which is attached does recreate how Steam's login window handles things. Note that what you are saying is exactly what happens.
Good to know that the testcase program still valid, thanks. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #32 from Austin Lund <austin.lund(a)gmail.com> 2010-06-22 18:23:59 --- Created an attachment (id=29075) --> (http://bugs.winehq.org/attachment.cgi?id=29075) WINEDEBUG=+win,+x11drv,+event wine a.exe 2>&1 | egrep '(event.X11DRV_ConfigureNotify|SetWindowPos.hwnd|sync_window_pos)' Attached is the output of WINEDEBUG=+win,+x11drv,+event wine a.exe 2>&1 | egrep '(event.X11DRV_ConfigureNotify|SetWindowPos.hwnd|sync_window_pos)' for the two situations of no load and full load (full load being 'for t in $(seq 10); do cat /dev/urandom > /dev/null & done'). This was done with wine-1.2-rc4-70-g802c4de. Though I will note that the harsh jumping has settled down considerably since 00b06dac85c096f20f7beed8898553166f07e6ad, but the calling of SetWindowPos back to a previous location does still occur. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #33 from Austin Lund <austin.lund(a)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). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #34 from Alexandre Julliard <julliard(a)winehq.org> 2010-06-24 06:54:45 --- (In reply to comment #33)
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.
No, we don't reconfigure the window in response to a ConfigureNotify. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #35 from Vincent Povirk <madewokherd(a)gmail.com> 2010-06-24 09:12:41 --- I can't find anything in the code to indicate that. I believe we don't reconfigure the window if the new position is the same as the last one we requested, but this isn't necessarily the case when we get a ConfigureNotify. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #36 from Alexandre Julliard <julliard(a)winehq.org> 2010-06-24 09:44:24 --- sync_window_position is not called when event_type == ConfigureNotify, dlls/winex11.drv/window.c around line 2338. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #37 from Austin Lund <austin.lund(a)gmail.com> 2010-06-24 18:02:33 --- (In reply to comment #36)
sync_window_position is not called when event_type == ConfigureNotify, dlls/winex11.drv/window.c around line 2338.
Hmm... OK. Then my test program perhaps does not recreate the problem. I'll have to look closer at what steam is doing. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #38 from el <elton(a)schiert.net> 2010-09-12 02:12:37 CDT --- I am experiencing a problem when resizing Steam windows. The window will not be resized to the indicated size; instead it will instantly jump to a smaller/larger size upon releasing the mouse button. Is this caused by the same bug? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #39 from Austin Lund <austin.lund(a)gmail.com> 2010-09-12 02:44:53 CDT --- (In reply to comment #38)
I am experiencing a problem when resizing Steam windows. The window will not be resized to the indicated size; instead it will instantly jump to a smaller/larger size upon releasing the mouse button. Is this caused by the same bug?
This bug is almost certainly fixed. I've noticed some other measuring style bugs which cause the window to be misplaced or wrongly sized, but I don't think they are related to this. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 Brandon Howard <FinalCrisisSX(a)Hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |FinalCrisisSX(a)Hotmail.com --- Comment #40 from Brandon Howard <FinalCrisisSX(a)Hotmail.com> 2010-09-14 01:08:37 CDT --- (In reply to comment #39)
This bug is almost certainly fixed. I've noticed some other measuring style bugs which cause the window to be misplaced or wrongly sized, but I don't think they are related to this.
What version are you using? Development? After 10 minutes of messing around in Wine 1.3.2 (plus a patch for Starcraft 1's battle.net menus to draw properly I doubt relate to this), this bug seems to still occur if I drag with left click around the top of Steam, but does NOT occur if I drag with Alt+Left-Drag from anywhere on the window. Which do you use? Descriptive: If I place the cursor next to the username text in the upper right hand corner (for positional reference), and move the window with a regular left click drag the right way / speed, it moves much further than I told it to when I let go of the button. Sometimes it even flies completely offscreen, never to be used again until restarted. Ive tried for quite some time now though to do this with Alt+Left-Drag, and it works just fine with no other ill effects that I see. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #41 from Austin Lund <austin.lund(a)gmail.com> 2010-09-14 01:21:26 CDT --- (In reply to comment #40)
What version are you using? Development? After 10 minutes of messing around in Wine 1.3.2 (plus a patch for Starcraft 1's battle.net menus to draw properly I doubt relate to this), this bug seems to still occur if I drag with left click around the top of Steam, but does NOT occur if I drag with Alt+Left-Drag from anywhere on the window. Which do you use?
Descriptive: If I place the cursor next to the username text in the upper right hand corner (for positional reference), and move the window with a regular left click drag the right way / speed, it moves much further than I told it to when I let go of the button. Sometimes it even flies completely offscreen, never to be used again until restarted. Ive tried for quite some time now though to do this with Alt+Left-Drag, and it works just fine with no other ill effects that I see.
There are two bugs here which makes this confusing. The original bug I described was that the window jumped back and fowards whilst being moved There is another bug which gives the window a strange offset when the mouse is released. The jumping whilst moving is due to the SetWindowPos and ConfigureNotify thing described here and it's fixed for me in the commit that Alexandre references. The jumping on release isn't fixed for me, but is clearly separate from this issue. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 --- Comment #42 from Alexey Loukianov <mooroon2(a)mail.ru> 2010-09-15 10:01:25 CDT --- This bug was de-facto hijacked from it's original meaning: initially it was about steam windows jumping while being moving but later on that was fixed. Then another bug was noticed with similar symptoms (jumping windows) occuring _after_ the window move and left mouse button release. Some mush had been create a new bugzilla entry about it but it had never happened leading to this bugreport hijack. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 Juan Lang <juan_lang(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #43 from Juan Lang <juan_lang(a)yahoo.com> 2010-09-15 11:13:55 CDT --- Let's mark this one fixed, then. Please open a separate bug for the others. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #44 from Alexandre Julliard <julliard(a)winehq.org> 2010-09-18 13:06:03 CDT --- Closing bugs fixed in 1.3.3. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20865 SheeEttin <sheeettin(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sheeettin(a)gmail.com --- Comment #45 from SheeEttin <sheeettin(a)gmail.com> 2010-10-01 01:47:34 CDT --- Bug reported re: jumping on release. It is bug 24579. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org