https://bugs.winehq.org/show_bug.cgi?id=56851
Bug ID: 56851 Summary: wineconsole runs at 20fps Product: Wine Version: 9.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: ikm@zbackup.org Distribution: ---
Created attachment 76657 --> https://bugs.winehq.org/attachment.cgi?id=76657 Continuously outputs text so you can see that scrolling is sluggish
Simply by running `wineconsole` and pressing some letter on your keyboard so it autorepeats you can already see that the console window is sluggish to refresh.
If that's not evident enough, run the attached `test.bat` in `wineconsole`, which will output some lines of text repeatedly. You can notice the way the text scrolls isn't smooth at all. It's at about 20fps.
Any application run by wineconsole is sluggish like that. This wasn't the case some years ago, where the updates were instantaneous.
I've traced this to commit 8ccf24ccb0a4362c407aea61927e604e60d41f6e ("conhost: Delay window refresh on output update"), which introduces a 50ms delay for the window refresh. There's no rationale as for why this change was made. It does make life miserable though. Please revert this unless there's some actual reason the console should run at 20fps. It used to be nice and speedy, now it's a slog.
https://bugs.winehq.org/show_bug.cgi?id=56851
Konstantin Isakov ikm@zbackup.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |8ccf24ccb0a4362c407aea61927 | |e604e60d41f6e CC| |jacek@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=56851
Konstantin Isakov ikm@zbackup.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |julliard@winehq.org
https://bugs.winehq.org/show_bug.cgi?id=56851
--- Comment #1 from Konstantin Isakov ikm@zbackup.org --- Added the original author and reviewer to CC.
https://bugs.winehq.org/show_bug.cgi?id=56851
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|wineconsole runs at 20fps |conhost runs at 20fps Regression SHA1|8ccf24ccb0a4362c407aea61927 | |e604e60d41f6e | CC| |eric.pouech@gmail.com
--- Comment #2 from Eric Pouech eric.pouech@gmail.com --- 1) changed title as the relevant component is conhost (wineconsole just ensures that program is run in conhost in window mode)
Made quick timing comparisons between native & wine. This requires to measure the same things: - ensure that window size & screen buffer size are equal between native and wine. Measurements made with screen buffer 120x9000 and window 120x30. - ensure that initial state of screen buffer is the same (adding cls on top of .bat) - adapt script to run and time execution over a given number of iterations (measurements done with 2000 and 20000 iterations)
native & wine on same HW, windows running under a VM
native exec time: - relatively stable between 2.6 & 2.8s (2000 iterations) - 27 to 28s (for 20000 iterations)
Wine exec time (current tip) - greater dispersion: 2.7 up to 3.7s (2000 iterations), average at 3.4s - 28 to 30s (20000 iterations)
Reversing patch tagged at culprit: - 2000 iterations on 155s!!
I think that's enough to remove the tagged SHA1 as a regression.
The reasons of commit 8ccf24ccb0a4362c407aea61927e604e60d41f6e is not to have an update for every single change, but to pack several changes into a single update.
Increasing the delay in update_window_config() will give slightly better execution time as it's going to reduce the number of window refreshes. But at the cost of having to wait longer for echo when you're typing. So I wouldn't favor that.
These figures should be confirmed by larger testing (and esp. on bare metal for windows), but as of today, considering with the 20000 iterations figures above (that somehow lower impact of startup time), I don't see a great discrepancy between Wine and native.
https://bugs.winehq.org/show_bug.cgi?id=56851
--- Comment #3 from Konstantin Isakov ikm@zbackup.org --- There is a host of interactive console applications (text editors/viewers, file managers etc), where the sluggish scrolling becomes a huge usability issue. If we're trying to match native in that respect, under Windows such applications have always been working very snappily (even 20 years ago with the orders of magnitude slower hardware).
If delayed window refresh is desirable for performance reasons, could we at least choose a better value than 50ms? 16ms would result in a pretty smooth 60fps experience. Sure, the throughput benchmarks would be a little worse, but the console isn't just used to see some scripts quickly executing, it is also used for (and was designed for) interactive applications. Experiencing 20fps there, in 2024, while using a modern multi-core computer with a discrete GPU, all in the name of performance, is honestly mind boggling to me.
I'd also like to note that any exact benchmark results under Linux would mostly be dependent on the X11/Wayland compositing/drivers in use, so it'd be more about benchmarking the Linux display stack than Wine itself. If the Linux display stack is slower than the native one, than it's the display stack which should be improved, shouldn't it be? Lowering the fps of the console just to match the Windows throughput numbers doesn't seem like the right solution. After all, no one throttles GUI applications under Wine just to match their native performance.
https://bugs.winehq.org/show_bug.cgi?id=56851
--- Comment #4 from Eric Pouech eric.pouech@gmail.com --- (In reply to Konstantin Isakov from comment #3)
There is a host of interactive console applications (text editors/viewers, file managers etc), where the sluggish scrolling becomes a huge usability issue. If we're trying to match native in that respect, under Windows such applications have always been working very snappily (even 20 years ago with the orders of magnitude slower hardware).
when you talk about scrolling, it's about shifting content up when adding new lines at the bottom of the console? (not the operation of scrolling with thumb bar the console window content), right?
If delayed window refresh is desirable for performance reasons, could we at least choose a better value than 50ms? 16ms would result in a pretty smooth 60fps experience. Sure, the throughput benchmarks would be a little worse, but the console isn't just used to see some scripts quickly executing, it is also used for (and was designed for) interactive applications. Experiencing 20fps there, in 2024, while using a modern multi-core computer with a discrete GPU, all in the name of performance, is honestly mind boggling to me.
quick measurement for the 50=>16 change show a 50% increase in overall runtime for 20k loops.
I'd also like to note that any exact benchmark results under Linux would mostly be dependent on the X11/Wayland compositing/drivers in use, so it'd be more about benchmarking the Linux display stack than Wine itself. If the Linux display stack is slower than the native one, than it's the display stack which should be improved, shouldn't it be?
Lowering the fps of the console just to match the Windows throughput numbers doesn't seem like the right solution. After all, no one throttles GUI applications under Wine just to match their native performance.
it seems to don't seem to agree on what's performance and how to measure it. your main argument is about converting the 50ms delay into fps.
I would argue that in the case of lots of consecutive ops (eg. cat of a large file), I don't see the point of displaying at 60fps, or even at 20fps. That's way faster that any human can read text. And the overall timing of all the ops matters (not the fps). (and for comparison, the famous ASCII Star Wars is at 15fps).
If your point is more oriented towards a single op (like page up on opened file), where we always add a 50ms delay for first op, we could rather introduce a variable delay strategy: - ie first op: immediate - and increase delay if consecutive ops arise in a limited time after first op (up to the current limit)
https://bugs.winehq.org/show_bug.cgi?id=56851
--- Comment #5 from Konstantin Isakov ikm@zbackup.org ---
when you talk about scrolling, it's about shifting content up when adding new lines at the bottom of the console?
I don't refer to cmd.exe, I refer to interactive Windows console programs, for example to FAR manager (https://appdb.winehq.org/objectManager.php?sClass=application&iId=953). You can use it as a text editor, viewer, you can browse files etc. By scrolling I mean continuously keeping the Up or Down buttons pressed and seeing the text on the screen to move up or down as a result.
My point is, Windows console subsystem isn't limited to just running .bat files with cmd.exe.
we could rather introduce a variable delay strategy:
Sure, but that would only help for short bursts of interactivity. When the burst sustains, you'd still have to decide what the sustained rate of updates should be. I'd still want that rate to be at least 60fps - even if the text scrolls fast and you can't read all of it, you can still see anomalies, like longer or empty lines, lines with different colors etc. Last but not least, there are simply aesthetical factors. I'd choose to spend 1% more of my CPU time (which is idling anyway) to get a more responsive console than to watch it stutter.
It'll always be a responsiveness vs throughput trade-off in the end, so I think the only sensible solution is to introduce an option to choose the desired FPS (with the possibility of choosing an arbitrary integer value, defaulting to 20, or disabling delaying updates entirely if one is so inclined). We already have options to choose font etc, it could live alongside it.
https://bugs.winehq.org/show_bug.cgi?id=56851
--- Comment #6 from Eric Pouech eric.pouech@gmail.com --- (In reply to Konstantin Isakov from comment #5)
when you talk about scrolling, it's about shifting content up when adding new lines at the bottom of the console?
I don't refer to cmd.exe, I refer to interactive Windows console programs, for example to FAR manager (https://appdb.winehq.org/objectManager.php?sClass=application&iId=953). You can use it as a text editor, viewer, you can browse files etc. By scrolling I mean continuously keeping the Up or Down buttons pressed and seeing the text on the screen to move up or down as a result.
My point is, Windows console subsystem isn't limited to just running .bat files with cmd.exe.
we could rather introduce a variable delay strategy:
Sure, but that would only help for short bursts of interactivity. When the burst sustains, you'd still have to decide what the sustained rate of updates should be. I'd still want that rate to be at least 60fps - even if the text scrolls fast and you can't read all of it, you can still see anomalies, like longer or empty lines, lines with different colors etc. Last but not least, there are simply aesthetical factors. I'd choose to spend 1% more of my CPU time (which is idling anyway) to get a more responsive console than to watch it stutter.
It'll always be a responsiveness vs throughput trade-off in the end, so I think the only sensible solution is to introduce an option to choose the desired FPS (with the possibility of choosing an arbitrary integer value, defaulting to 20, or disabling delaying updates entirely if one is so inclined). We already have options to choose font etc, it could live alongside it.
I don't like the idea to make it configurable. It looks like a too complicated feature for regular users. OTOH, current structure of conhost (ie single threaded with all requests to read/write console contents *AND* redisplaying in window mode) likely influenced the current design strategy. Perhaps having a dedicated thread for rendering console content might be an alternate design. Still need to measure the impact of synchronisation between the two threads, but that would make things easier in the long run. But that would a larger change.
-
WineHQ Bugzilla