1. 53
  1.  

  2. 7

    See also.

    I’ll also note that the Kindle 4 and Paperwhite don’t belong in the mobile device comparison because they use e-ink screens which explicitly trade latency for high-light visibility and low power draw; and as a result, they’re designed with zero latency-sensitive animations or interactions. (What’s the “latency” on turning the page in a book, anyway?)

    1. 4

      If you like this, I highly recommend watching this talk by John Carmack about latency in VR systems:

      https://www.youtube.com/watch?v=lHLpKzUxjGk

      I’m not a VR enthusiast, but I hope it takes off so that laggy hardware and software will make people sick rather than just silently annoying them :-/ That should benefit the rest of the industry.

      1. 2

        For desktop results, results are measured from when the key started moving until the screen finished updating.

        Yet again let down by poor measurement methodology. Pressing the key from zero travel to activation is not “Latency” because that activation point in the key travel is fixed in reference to the force response of the key switch, and as such is understood as the base “activation point” for computer users. As they type, they do not expect a letter to appear on the screen the moment they begin to press the key, or at the same exact key travel of each switch. Many switches have very short travel distance, while others will have a longer travel, and thus a deeper activation point and a different force response, which would then be understood by that user and would change the way in which they activate the switches and expect characters to appear on the screen after activation. All of this in account, comparing these computers with this extra travel distance measured in the sum is poor science because it brings in a variable that doesn’t necessarily count towards what we’re trying to measure.

        1. 4

          I think this is a valid criticism, though it doesn’t totally impeach the results. For example, the Apple IIe with 30ms latency has a mechanical keyswitch with 3.0mm of travel. The Lenovo X1 Carbon 4th gen (full disclosure: this was my laptop) with 110ms/150ms latencies has 1.5mm of key travel. Key travel is not a significant enough factor to change or reverse the latency numbers. If anything, they make the Lenovo look less bad.

          I agree that key travel (and probably activation force) are unnecessary noise in the numbers, but as the modern machines are mostly laptops it’s only going to falsely improve their relative latency. I like your suggestion downstream to short the keyboard to eliminate the extra variable, and suggested the same thing to Luu during the writing of his previous latency post).

          1. 3

            As they type, they do not expect a letter to appear on the screen the moment they begin to press the key

            I do. It’s the intuitive behavior. I understand aspects of processing the stuff in between the key press and rendering of the character can cause a delay. My mental model says there should be almost no perceptible delay for something simple like a text editor on a basic GUI. With no overhead for fancy analysis or rendering, the text should appear on the screen instantly with a delay only happening if I delay or add one in the system to slow it down for usability. I’m not sure if the last point really matters but popped in my head.

            What does bother me on my Android phone is the delays of text appearing. I actually screws me up when I’m typing. This happens on some web forms on my desktop as well. When I can just type and see text, I can throw it out much more quickly with my mistakes getting fixed more quickly. If text loop is efficient, I might also even have extra CPU available for other things.

            1. 7

              I agree there should ideally be no latency between the keypress and something happening, but I think what @kel is talking about is whether users expect there to be 0 latency between beginning to press the key and something happening, which is what the linked post is measuring. For keyboards that have non-negligible travel, I think most users think of the keypress happening sometime later than the beginning of travel, closer to the time that the key hits the bottom. (On an old mechanical keyboard it’d be when you hear the click, of course.)

              To me it’s annoying if there’s a delay after I properly press the key, but on a high-travel keyboard it doesn’t annoy me that there’s nonzero time for the key to depress and activate, since there’s plenty of mechanical feedback about what’s going on there, so I don’t really perceive it as computer latency.

              1. 2

                You’ve got it. The fix to this I think would be to use a single simple switch across every machine, wired temporarily to the contacts that the switch of the keyboard uses, so that the latency of a normally associated keyboard, its controller, and communication scheme would still be factored into understanding the total latency of the system in a fairly sterile situation.

                Some stupid users like me prefer switches that have a nice, big throw :)

                1. 1

                  That makes plenty sense. Yeah, I do allow for the key to hit the bottom before expecting anything.