https://bugs.winehq.org/show_bug.cgi?id=56210
Bug ID: 56210 Summary: Very slow event processing (seconds) Product: Wine Version: 9.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: nagle@animats.com Distribution: ---
The Windows event queue, as emulated under Wine, appears to work differently than the real one under Windows 10.
If you build my Rust test program, ui-mock, arc branch:
[code] git clone https://github.com/John-Nagle/ui-mock.git cd ui-mock git checkout arc cargo build --release --target x86_64-pc-windows-gnu --examples cd target/x86_64-pc-windows-gnu/release/examples wine ui-mock.exe [/code]
it will run fine under real Windows 10. But, built on Ubuntu 22.04 LTS with current Rust, it behaves strangely. Click on one of the big bars that says "placeholder", and you get get a login popup. It doesn't do anything; this is just a GUI dummy. Type something into the user name box.
On real Windows, characters are echoed at full speed.
[b]Under Wine 8 or 9, character echo is delayed about 3-4 seconds.[/b]
What seems to be happening is that the endless refreshing of the screen (this is a game-type program) is starving out event processing.
This uses the Rust crates Rend3, Winit, egui, and wgpu, all of which work cross-platform. A newer version of Rend3 (see the Cargo.toml file for the rev number) has a different approach to the event loop. There are two callback functions - "event", and "redraw" in Rend3's framework. The framework itself does a request-redraw at the end of each redraw. This seems to starve out non-redraw event processing.
An earlier version of Rend3 did not have this problem. That older version can be built as above, by removing the line
git checkout arc
This uses a different version of the Rend3 framework, one which only redraws when the event queue is empty.
"winit", a standard Rust crate, claims in its documentation that non-redraw events are always processed before redraws. But "winit", which has platform-dependent code for Windows, seems to assume, in the Windows platform code, that the underlying platform event queue does that. For real Windows, it does seem to do that. But Wine's event queue does not seem to work that way.
If someone reports this problem in a commercial game, it's probably going to be reported as "keys are sluggish". Here, you have sources for everything and can reproduce the problem.