Comment by wky
5 hours ago
The perceived latency starts from keydown, not keyup. Redefining latency to start at keyup reduces measured latency, not perceived latency, and delaying the visual display to keyup makes perceived latency strictly worse, not better. Even sticking with the keyup definition, just displaying the result as soon as it is available gives the possibility of negative (defined) latency.
I think you don't fully understand. They aren't just doing a search based on the key being pressed down. They already did a search based on the previous characters that returned results for all possible next characters. So by the time you type a second character it just checks results locally from the search that had likely already been returned from when you had typed the previous character.
They do that, yet proceed to kneecap the perceived latency by delaying the render.
> And on keyUp (the user releases the key), we render the suggestions.
There are a large number of edge cases where rendering it on key down would not be desirable (user types Ctrl+v, how accented characters are enetered, how some Asian languages get handled, backspace/delete, user holds a key down, etc). This is getting into the point of optimization where it simply does not matter and can actually harm things
1 reply →