The appended patch against the CVS version fixes one issue for me.
The game "TacOps" (a standalone 2D wargame, not to be mixed up with the Unreal mod "Tac Ops") uses home-grown scrollbars. They have autorepeat, that means holding the mouse button on the "down" or "up" icons will continue to scroll until you release the button. Without the appended patch Wine will never notice when you release the mouse button. That effectively means an application hang since you can never do anything else anymore, as the game continue to execute "down" autorepeat.
To reproduce, download the demo at http://www.battlefront.com/products/tacops4/demo.html . Set up your units as per the instructions (place from floating window into the grey box). The scrollbars in question are under artillery support and under air support. Clicking on the up/down icons in the scrollbars will hang the application without the patch and will work with the patch. Please mail me if you want a better walkthrough.
In case the patch attachment gets stripped by the list I put a copy of the patch here: http://www.cons.org/cracauer/wine-tacops-2.diff
Martin
Martin Cracauer wrote:
The game "TacOps" (a standalone 2D wargame, not to be mixed up with the Unreal mod "Tac Ops") uses home-grown scrollbars. They have autorepeat, that means holding the mouse button on the "down" or "up" icons will continue to scroll until you release the button. Without the appended patch Wine will never notice when you release the mouse button. That effectively means an application hang since you can never do anything else anymore, as the game continue to execute "down" autorepeat.
You'll probably need Alexandre's comment on this, but it doesn't look correct to me.
Querying the X server for the key state on each call to GetAsyncKeyState bypasses the input queue, and is likely to cause applications that poll GetAsyncKeyState to slow down...
This is likely to be a tricky problem to solve, as you need to run Wine's X11 message loop, but Wine currently only does that when the application waits for input.
Mike
Mike McCormack wrote on Thu, Jan 25, 2007 at 06:42:25PM +0900:
Martin Cracauer wrote:
The game "TacOps" (a standalone 2D wargame, not to be mixed up with the Unreal mod "Tac Ops") uses home-grown scrollbars. They have autorepeat, that means holding the mouse button on the "down" or "up" icons will continue to scroll until you release the button. Without the appended patch Wine will never notice when you release the mouse button. That effectively means an application hang since you can never do anything else anymore, as the game continue to execute "down" autorepeat.
You'll probably need Alexandre's comment on this, but it doesn't look correct to me.
Querying the X server for the key state on each call to GetAsyncKeyState bypasses the input queue, and is likely to cause applications that poll GetAsyncKeyState to slow down...
I have seen in other parts of the code that a call like mine is only made no more often than 100msec.
That will still cause a systemcall for getting the time, but it'll probably fix my application problem (at work right now, can't test) and at the same time make the code much lighter so that polling GetAsyncKeyState won't slow down.
Does that sound better?
Also keep in mind I only query the X11 server when the keycode is one of a selected few. Combined with a 100msec cap that should keep the extra load down.
This is likely to be a tricky problem to solve, as you need to run Wine's X11 message loop, but Wine currently only does that when the application waits for input.
The application is just sitting in the GUI waiting for me to poke around. But it is one of those applications with permanent 100% CPU load, so it is clearly not doing some select() equivalent.
Martin
-
Martin Cracauer -
Mike McCormack