Re:Terminal latency (2017)
by microcolonel on Wednesday March 20, 2019 @05:32PM
(#19447167)
> Every time I click on a menu in macOS (Safari, for example, which I am using as I write this) I can almost hear it go "kachunk." Not even 10ms. ;-( Maybe the delay is an intentional fade-in or ... something, but I still hate it.
Not to be too down on one player, but Apple is especially bad for this. GTK+ is considered slow by many, but compared to Cocoa, it's an SR-71. Cocoa rarely ever completes a window resize fast enough to hit a 60Hz VSync, GTK+ at least usually keeps up with 144Hz (for me) if you have a good GPU, and 60Hz if you have anything faster than a mid-grade Sandybridge IGP. Depending on the application, Qt is also sometimes dramatically faster than GTK+ (though on Linux the controls are somewhat clunky, since they seem to be emulating some Windows control behaviours which did not stand the test of time).
Cooperative Multitasking may have been a massive hack but boy was it ever responsive when you selected a menu back in System 7
Re:Terminal latency (2017)
by microcolonel on Wednesday March 20, 2019 @09:57PM
(#19448687)
I think some of the benefit of this could be replicated in a preemptive system if your process could yield to a specific other process, and grant your remaining scheduler time (and maybe some of the target's) to the target of your IPC, and preempt the preemption.
10ms of added latency is very irritating - even adding 4ms feels clunky on guitar/headphones and that's typical for playing through a DAW and digital effects. As much as I like the iPad ... drawing on it is still like drawing underwater, and touch-to-sound latency is still too high in many cases. On the other hand... I can almost tolerate a bit of latency playing a weighted keyboard because I imagine that a hammer is hitting a string so I adjust my playing accordingly. The keyboard also seems to trigger before the note bottoms out, which helps a bit (except when you're playing very quietly.)
There was a terrible idea in the CRT era that when a user clicked on a menu you could do all sorts of computation to update menu contents and still have time to draw the menu before the next ~80Hz refresh. Even if you missed a frame "humans couldn't notice it."
Unfortunately this failed horribly in practice because it frequently pushed things over the edge, resulting in two frames of latency (or many more if latency wasn't managed well) which made things feel sluggish and unresponsive.
Even in 2019, though we have 120+ Hz user interfaces, asynchronous refresh, multi-gigahertz processors, and insane GPUs, menus are still clunky. Every time I click on a menu in macOS (Safari, for example, which I am using as I write this) I can almost hear it go "kachunk." Not even 10ms. ;-( Maybe the delay is an intentional fade-in or ... something, but I still hate it.
Moral of the story: 10ms is terrible, and every bit of delay you add to a UI can push it (and your users) closer to the edge.