5 ms·

While you might be slightly right, my experience tuning windows machines leads me to believe your missing the mark. I'm going to say the three largest contribu

While you might be slightly right, my experience tuning windows machines leads me to believe your missing the mark. I'm going to say the three largest contributions to general desktop lag are: Animations and intentional delays. It can't be said, how much faster a machine feels when something like MenuShowDelay is decreased to 0, or the piles of animations are sped up. Too many layers between the application draw commands and the actual display. All this compositing, vsync, and minimal 2d acceleration creates a low level persistent lag. Disabling aero on a win7 machine does wonders to its responsiveness. But even then pre-vista much of the win32 GDI/drawing API was basically implemented in hardware on the GPU. If you get an old 2d win32 API benchmark, you will notice that modern machines don't tend to fare well in raw API call performance. 30 seconds poking around on youtube, should find you a bunch of comparisons like this https://www.youtube.com/watch?time_continue=25&v=ay-gqx18UTM&feature=emb_logo https://www.youtube.com/watch?time_continue=25&v=ay-gqx18UTM.... Keep in mind that even in 2020 pretty much every application on the machine is still relying on GDI (same as linux apps relying on xlib). Input+processing lag, USB is polling with a fairly slow poll interval rate (think a hundred or so ms). Combined with the fact that the keystrokes/events then end up queued/scheduled through multiple subsystems before eventually finding their way to the correct window, and then having to again reschedule and get the application to retrieve and process it via GetMessage()/etc. Basically, this is more a function of modern software bloat, where all those layers of correct architecture add more overhead than the old school get the ps2 interrupt, post a message to the active window queue, schedule the process managing the window messages. (https://social.technet.microsoft.com/Forums/windows/en-US/b18330ea-ded6-48ae-a524-da065eafaef1/changing-usb-polling-rate-x64?forum=w7itprohardware https://social.technet.microsoft.com/Forums/windows/en-US/b1...) There are a number of other issues, but you can retune those three areas to some extent, and the results are a pretty noticeable improvement. Having someone at MS/etc go in and actually focus on fixing this might have a massive effect with little effort. But that doesn't appear to be in the cards, since they appear to be more interested in telemetry and personal assistants.

cellularmitosis 6y ago
> Disabling aero on a win7 machine does wonders to its responsiveness. Tragically, it seems the only way to completely get rid of tearing in youtube is to re-enable Aero :( (at least with nvidia hardware). RIP classic.
- StillBored 6y ago
  I don't know if this still works, but nvidia had a "program settings" override, where you could select a .exe and force vsync on for particular programs. Might try messing with that. I did that for media player classic a long time ago.
- zozbot234 6y ago
  The thing is, you will always have tearing if you disable vsync (and compositing) for the sake of low latency. But tearing is only really perceivable when watching full-screen videos and animations, which is quite a different use case from general computer use.
blattimwind 6y ago
> Animations and intentional delays. It can't be said, how much faster a machine feels when something like MenuShowDelay is decreased to 0, or the piles of animations are sped up. These animations effectively increase the input lag significantly. Even with them turned off there are extra frames of lag between a click and the updated widget fully rendering. (Everything below refers to a 60 Hz display) For example, opening a combo-box in Windows 10 with animations disabled takes two frames; the first frame draws just the shadow, the next frame the finished open box. With animations enabled, it seems to depend on the number of items, but generally around 15 frames. That's effectively a quarter second of extra input lag. A menu fading in takes about ~12 frames (0.2 seconds), but at least you can interact with it partially faded in. Animated windows? That'll be another 20 frame delay, a third of a second. Without animations you're down to six, again with some half-drawn weirdness where the empty window appears in one frame and is filled in the next. (So if you noticed pop-ups looking slightly weird in Windows, that's why). I assume these two-frame redraws are due to Windows Widgets / GDI and DWM not being synchronized at all, much like the broken redraws you can get on X11 with a compositor. > USB is polling with a fairly slow poll interval rate (think a hundred or so ms). The lowest polling rate typically used by HID input devices is 125 Hz (bInterval=8), while gaming hardware usually defaults to 500 or 1000 Hz (bInterval=2 or 1). Most input devices aren't that major a cause of input lag, although curiously a number of even new products implement debouncing incorrectly, which adds 5-10 ms; rather unfortunate. https://epub.uni-regensburg.de/40182/1/On_the_Latency_of_USB-Connected_Input_Devices_author_version.pdf https://epub.uni-regensburg.de/40182/1/On_the_Latency_of_USB...
- derefr 6y ago
  > For example, opening a combo-box in Windows 10 with animations disabled takes two frames; the first frame draws just the shadow, the next frame the finished open box. With animations enabled, it seems to depend on the number of items, but generally around 15 frames. That's effectively a quarter second of extra input lag. This isn't usually what I think of when I think of "latency." Latency is, to me, the time between when the user inputs, and when the system recognizes the action. This becomes especially problematic in situations where events get queued up, and then the extra latency causes an event to attach to something that is now in a different state than the user perceived it to be when they did the input—e.g. double-clicking on an item in a window you're closing right after telling the system to close the window, where you saw the window as open, but your event's processing was delayed until after the window finished closing, such that now you've "actually" clicked on something that was, at the time, behind the window. On the other hand, the type of latency you're talking about—between when the system recognizes input, and when it finishes displaying output—seems much less troublesome to me. We're not playing competitive FPS games here. Nobody's trying to read-and-click things as fast as possible, lest something horrible happen. And even if they were, the "reading" part of reading-and-clicking needs to be considered. Can people read fast enough that shaving off a quarter-second of display time benefits them? And, more crucially, does cutting that animation time actually cause users to be able to read the text faster? Naively you'd assume it would; but remember that users have to move their eyes to align with the text, to start reading it. If the animated version more quickly "snaps" the user's eyes to the text than the non-animated version, then in theory the user using the animated combo-box might actually be able to select an option faster! (And remember, none of this matters for users who are acting on reflex; without the kind of recognition latency I mentioned above, the view controller for the combo-box will be instantly responsive to e.g. keyboard input, even while the combo-box's view is still animating into existence. Users who already know what they want, don't need to see the options in order to select them. In fact, such users won't usually bother to open the combo-box at all, instead just tabbing into it and then typing a text-prefix to select an option.)
derefr 6y ago
Sure. Mind you, my argument wasn't comparing Windows to these sorts of "lightning-fast" systems—(modern) Windows isn't even a contender. Nor is macOS, nor KDE or GNOME. My points were under the mode of thought where you look at a modern system already aimed at being "fast because it's lightweight" (e.g. XFCE), and then you ask why it still feels laggy compared to BeOS/AmigaOS/etc. Where such "lightweight" DEs do have perceivable latency, that latency mostly comes down to operations hitting the disk where these older systems didn't. (Also the input stack, yes, but that's not universal: modern hardware still has PS/2 ports, and modern OSes still access those with rather direct reads. Many gamers swear by PS/2 peripherals—though probably mostly for cargo-cult reasons.) Some of the minimal-est Linux WMs, e.g. Fluxbox, are run entirely from memory once started, and so are comparably fast—but need an explicit restart/reload to do anything. Plus, the apps launched in the WM aren't designed with the same paradigm, so most of your experience there is still slow.
- vidarh 6y ago
  To expand on your point, one of my favourite examples of how slow a lot of software has become: A few years back I tested load time for a default Ubuntu emacs install in a console against "booting" the Linux-hosted version of AROS (an AmigaOS reimplementation) with a customized startup-sequence (AmigaOS boot script) that started FrexxEd (an AmigaOS editor co-written by the author of Curl). AROS goes through the full AmigaOS-style boot, registering devices, and everything. It handily beat my Emacs startup. Now, you can make Emacs start quicker, and FrexxEd is not by default as capable (but it's scriptable with a C-like scripting language), but there's no wonder people feel software has gotten slower, because so often the defaults assume we're prepared to wait. E.g. one of my pet peeves with typical Emacs installations: Try misconfiguring your DNS and watch it hang until the DNS lookups fail.... It's not an inherent flaw in Emacs; you can certainly prevent it from happening, but so many systems have Emacs installations where you face a long wait. Normally of course this is not a big issue, but those setups still have a DNS lookup in the critical path for startup that adds yet one more little delay. All of these things add up very quickly. In the cases where these things are an issue in older software, they tend to either need to be explicitly enabled, or there is concurrency. I submitted some patches to AROS years ago, to implement scrollback buffers and cut and paste in the terminal, and one of the things it really brought back is how cautious AmigaOS was in making everything painstakingly concurrent all over the place. At the cost of throughput but cutting apparent responsiveness. E.g. when you cut and paste from a console window on AmigaOS, data about the copied region gets passed to a daemon that will write it to a clips: device. It gets passed to a separate daemon because the clips: device that the clibboards are stored to, like everything else in AmigaOS can be "assigned" to another location. By default it is stored in T: (temporary). By default T: points to a RAM disk. However, clips: or T: could very well have been reassigned to MyClipboardFloppy:. In which case copying would prompt you to insert the floppy labeled MyClipboardFloppy: after which writing the copied section would take way too long. (That actual write to the floppy would happen in yet another task) So copying as a high level system service is handled in a separate task (thread). Everywhere throughout the system everything that could ever potentially be slow, and on a 7.16MHz 68k machine with floppies and limited RAM that was a lot of things, would be done in separate tasks so that at least the user could just get on with other things in the meantime. "Other things" then as a consequence often meant "just keep using the current application" because the concurrency would mean a lot of these things would lazily happen in the background. For e.g. a typical shell session, just pressing a key will involve half a dozen tasks or so, e.g. gradually "cooking" the input from a raw keyboard event, to an event for a specific window, to a event to a specific console device attached to a window, to an event to a high level "console handler" that handles complex events such as e.g. auto-complete, to the shell itself. It is inefficient in terms of throughput, but because the system will preempt high priority tasks (including user input related ones), and react with low latency and offload less latency critical tasks to other tasks, the system feels fast. A key to this was that on a system that slow, a lot of the things that could be slow, would regularly be slow for the developers and would get fixed so that you'd opt in to the slow behaviour. E.g. I doubt most people using Emacs are ever aware if their installation is slowed down by DNS lookups on startup for example, because most of the time it's fast enough that you won't really notice that one extra little papercut.
justin66 6y ago
USB is polling at 1000hz now if the devices support it, it's really not bad. On the hardware side, displays are really the part that still needs some work in terms of latency, and FreeSync and G-Sync are evidence that the problems are at least being considered. The hardware in the PC itself is pretty good. On the software side, operating systems, desktop environments, GUI SDKs, frameworks, and so on could all take the problem a lot more seriously, but I wouldn't hold my breath waiting for that. There are too many people involved who believe it's reasonable to pause and play a little animation before doing what the user asked for.

cellularmitosis 6y ago

> Disabling aero on a win7 machine does wonders to its responsiveness. Tragically, it seems the only way to completely get rid of tearing in youtube is to re-enable Aero :( (at least with nvidia hardware). RIP classic.

StillBored 6y ago
I don't know if this still works, but nvidia had a "program settings" override, where you could select a .exe and force vsync on for particular programs. Might try messing with that. I did that for media player classic a long time ago.
zozbot234 6y ago
The thing is, you will always have tearing if you disable vsync (and compositing) for the sake of low latency. But tearing is only really perceivable when watching full-screen videos and animations, which is quite a different use case from general computer use.

blattimwind 6y ago

> Animations and intentional delays. It can't be said, how much faster a machine feels when something like MenuShowDelay is decreased to 0, or the piles of animations are sped up. These animations effectively increase the input lag significantly. Even with them turned off there are extra frames of lag between a click and the updated widget fully rendering. (Everything below refers to a 60 Hz display) For example, opening a combo-box in Windows 10 with animations disabled takes two frames; the first frame draws just the shadow, the next frame the finished open box. With animations enabled, it seems to depend on the number of items, but generally around 15 frames. That's effectively a quarter second of extra input lag. A menu fading in takes about ~12 frames (0.2 seconds), but at least you can interact with it partially faded in. Animated windows? That'll be another 20 frame delay, a third of a second. Without animations you're down to six, again with some half-drawn weirdness where the empty window appears in one frame and is filled in the next. (So if you noticed pop-ups looking slightly weird in Windows, that's why). I assume these two-frame redraws are due to Windows Widgets / GDI and DWM not being synchronized at all, much like the broken redraws you can get on X11 with a compositor. > USB is polling with a fairly slow poll interval rate (think a hundred or so ms). The lowest polling rate typically used by HID input devices is 125 Hz (bInterval=8), while gaming hardware usually defaults to 500 or 1000 Hz (bInterval=2 or 1). Most input devices aren't that major a cause of input lag, although curiously a number of even new products implement debouncing incorrectly, which adds 5-10 ms; rather unfortunate. https://epub.uni-regensburg.de/40182/1/On_the_Latency_of_USB-Connected_Input_Devices_author_version.pdf https://epub.uni-regensburg.de/40182/1/On_the_Latency_of_USB...

derefr 6y ago
> For example, opening a combo-box in Windows 10 with animations disabled takes two frames; the first frame draws just the shadow, the next frame the finished open box. With animations enabled, it seems to depend on the number of items, but generally around 15 frames. That's effectively a quarter second of extra input lag. This isn't usually what I think of when I think of "latency." Latency is, to me, the time between when the user inputs, and when the system recognizes the action. This becomes especially problematic in situations where events get queued up, and then the extra latency causes an event to attach to something that is now in a different state than the user perceived it to be when they did the input—e.g. double-clicking on an item in a window you're closing right after telling the system to close the window, where you saw the window as open, but your event's processing was delayed until after the window finished closing, such that now you've "actually" clicked on something that was, at the time, behind the window. On the other hand, the type of latency you're talking about—between when the system recognizes input, and when it finishes displaying output—seems much less troublesome to me. We're not playing competitive FPS games here. Nobody's trying to read-and-click things as fast as possible, lest something horrible happen. And even if they were, the "reading" part of reading-and-clicking needs to be considered. Can people read fast enough that shaving off a quarter-second of display time benefits them? And, more crucially, does cutting that animation time actually cause users to be able to read the text faster? Naively you'd assume it would; but remember that users have to move their eyes to align with the text, to start reading it. If the animated version more quickly "snaps" the user's eyes to the text than the non-animated version, then in theory the user using the animated combo-box might actually be able to select an option faster! (And remember, none of this matters for users who are acting on reflex; without the kind of recognition latency I mentioned above, the view controller for the combo-box will be instantly responsive to e.g. keyboard input, even while the combo-box's view is still animating into existence. Users who already know what they want, don't need to see the options in order to select them. In fact, such users won't usually bother to open the combo-box at all, instead just tabbing into it and then typing a text-prefix to select an option.)

derefr 6y ago

Sure. Mind you, my argument wasn't comparing Windows to these sorts of "lightning-fast" systems—(modern) Windows isn't even a contender. Nor is macOS, nor KDE or GNOME. My points were under the mode of thought where you look at a modern system already aimed at being "fast because it's lightweight" (e.g. XFCE), and then you ask why it still feels laggy compared to BeOS/AmigaOS/etc. Where such "lightweight" DEs do have perceivable latency, that latency mostly comes down to operations hitting the disk where these older systems didn't. (Also the input stack, yes, but that's not universal: modern hardware still has PS/2 ports, and modern OSes still access those with rather direct reads. Many gamers swear by PS/2 peripherals—though probably mostly for cargo-cult reasons.) Some of the minimal-est Linux WMs, e.g. Fluxbox, are run entirely from memory once started, and so are comparably fast—but need an explicit restart/reload to do anything. Plus, the apps launched in the WM aren't designed with the same paradigm, so most of your experience there is still slow.

vidarh 6y ago
To expand on your point, one of my favourite examples of how slow a lot of software has become: A few years back I tested load time for a default Ubuntu emacs install in a console against "booting" the Linux-hosted version of AROS (an AmigaOS reimplementation) with a customized startup-sequence (AmigaOS boot script) that started FrexxEd (an AmigaOS editor co-written by the author of Curl). AROS goes through the full AmigaOS-style boot, registering devices, and everything. It handily beat my Emacs startup. Now, you can make Emacs start quicker, and FrexxEd is not by default as capable (but it's scriptable with a C-like scripting language), but there's no wonder people feel software has gotten slower, because so often the defaults assume we're prepared to wait. E.g. one of my pet peeves with typical Emacs installations: Try misconfiguring your DNS and watch it hang until the DNS lookups fail.... It's not an inherent flaw in Emacs; you can certainly prevent it from happening, but so many systems have Emacs installations where you face a long wait. Normally of course this is not a big issue, but those setups still have a DNS lookup in the critical path for startup that adds yet one more little delay. All of these things add up very quickly. In the cases where these things are an issue in older software, they tend to either need to be explicitly enabled, or there is concurrency. I submitted some patches to AROS years ago, to implement scrollback buffers and cut and paste in the terminal, and one of the things it really brought back is how cautious AmigaOS was in making everything painstakingly concurrent all over the place. At the cost of throughput but cutting apparent responsiveness. E.g. when you cut and paste from a console window on AmigaOS, data about the copied region gets passed to a daemon that will write it to a clips: device. It gets passed to a separate daemon because the clips: device that the clibboards are stored to, like everything else in AmigaOS can be "assigned" to another location. By default it is stored in T: (temporary). By default T: points to a RAM disk. However, clips: or T: could very well have been reassigned to MyClipboardFloppy:. In which case copying would prompt you to insert the floppy labeled MyClipboardFloppy: after which writing the copied section would take way too long. (That actual write to the floppy would happen in yet another task) So copying as a high level system service is handled in a separate task (thread). Everywhere throughout the system everything that could ever potentially be slow, and on a 7.16MHz 68k machine with floppies and limited RAM that was a lot of things, would be done in separate tasks so that at least the user could just get on with other things in the meantime. "Other things" then as a consequence often meant "just keep using the current application" because the concurrency would mean a lot of these things would lazily happen in the background. For e.g. a typical shell session, just pressing a key will involve half a dozen tasks or so, e.g. gradually "cooking" the input from a raw keyboard event, to an event for a specific window, to a event to a specific console device attached to a window, to an event to a high level "console handler" that handles complex events such as e.g. auto-complete, to the shell itself. It is inefficient in terms of throughput, but because the system will preempt high priority tasks (including user input related ones), and react with low latency and offload less latency critical tasks to other tasks, the system feels fast. A key to this was that on a system that slow, a lot of the things that could be slow, would regularly be slow for the developers and would get fixed so that you'd opt in to the slow behaviour. E.g. I doubt most people using Emacs are ever aware if their installation is slowed down by DNS lookups on startup for example, because most of the time it's fast enough that you won't really notice that one extra little papercut.

justin66 6y ago

USB is polling at 1000hz now if the devices support it, it's really not bad. On the hardware side, displays are really the part that still needs some work in terms of latency, and FreeSync and G-Sync are evidence that the problems are at least being considered. The hardware in the PC itself is pretty good. On the software side, operating systems, desktop environments, GUI SDKs, frameworks, and so on could all take the problem a lot more seriously, but I wouldn't hold my breath waiting for that. There are too many people involved who believe it's reasonable to pause and play a little animation before doing what the user asked for.