John Siracusa“Apple II Forever” indeed…
Francis 🏴☠️ Gulotta@siracusa 150ms!?
xot@siracusa Yeah, that seems very wrong. Apple II should be about 8.3 ms on average, strictly based on the time it takes an NTSC signal to paint the CRT. The time it takes for a key press to put a character into display RAM is about 10 microseconds (10 cycles at 1.023 MHz).
Niki@siracusa We measured MBP 2021 (120 Hz) at ~40ms. 100ms sounds way too much for 2014 MBP https://late-mate.com/old/updates/003/update-003
Ivan Reese@nikitonsky @siracusa would love to get my hands on a late mate, just sayin
@spiralganglion I’ll ask Dan if he had any prototypes left, if yes, will send you one!
Marcin Wichary@nikitonsky @siracusa I imagine this is skipping both the keyboard matrix scanning and maybe also using a more typical (slower) word processor as software, although the delta is still too large to explain both I think?
Fazal Majid@nikitonsky @siracusa it depends on the app, of course. Terminal.app is nearly 10x faster than iTerm2, for instance:
Jim Luther@siracusa I dunno how the numbers here were obtained, but the software stack between the keyboard and the screen is huge on modern OSs.
@siracusa I read the article and the conclusions are not surprising. When I first started in Apple engineering (back in the stone ages of Mac System 7.5.x) some of the first file system code I wrote was in C and wasn’t very efficient. My manager had me rewrite it explaining that because my code was going into the OS, it needed to be as small, fast, and efficient as possible because it would affect everything that used it - if there was a performance problem, it shouldn’t be because of sloppy OS code.
Mr Audio@jimluther @siracusa We were asked once, why was touch to sound so slow on touch devices. We said our audio system is capable of the lowest latency on any modern OS. Lower the IO buffer size we said. Still too high they said. Turns out touching the screen to an event being registered was like 17ms. We said start there. 🙂
butternut@siracusa not referring to the pictured keyboard-to-screen metrics specifically, but their measurement methodology for other things may be flawed. If you watch the video, the example with switching slack channels taking 225ms includes 40+ms where the finger is touching the screen before it comes up. Most iOS apps trigger button actions on “touch up inside” so really the timing should start when the finger is removed, not when it’s put down. Triggering on “touch up” instead of “touch down” feels like an unavoidable consequence of how people have been trained to use modern touchscreen devices — where if you tap something by accident, you can slide your finger away before lifting it up and the button action won’t go through. Feels like the timer should start when the finger comes up since that’s when the user is committed to their action.
This made me question their methodology for other measurements in the article and seems to track with others here who think their numbers are too high.
sconient@butternut Touch devices have to register a "press" on finger lift because the same touch action is used to drag and scroll. Even in apps that don't use drag or scroll, registering a press on "touch down" would be inconsistent with the majority and likely cause user frustration.
Guy English@siracusa If you’re new to Ink & Switch they’ve a lot of interesting ideas. The “local first software” seems kind of funny to our eyes but they argue for it for good reasons. They’re taking to time to think about what computers could be, at least, and that brings me joy.
Jim Zajkowski@siracusa the benchmark would have to be the Selectric
dxzdb
Fedor Indutny
Ludovic :Firefox: :FreeBSD:@siracusa in french we say fort et vert
Niavy 
Matt Craig@siracusa IIe, sorry not sorry.
And we shall not discuss the III