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)