The math doesn’t work

Computer CPU clock speeds are now well into the gigaHertz range, meaning that there are potentially billions of things per second that can be done by the computer. Billions. Thousands of millions of cycles per second.

Why then is it impossible for my tablet to keep up with my typing? I’m not a fast typist, but a modern computer should be able keep up with the kind of fantasy, hyper typing that pushes the limits of the human hand’s ability to withstand the G forces involved in moving the fingers.

You can record audio and video simultaneously and with fairly good resolution with this thing, and one would think that taking key pad instructions at rates of a few hundred strokes per minute, converting them to text, displaying the text on screen and making a click noise would not tax the computing power beyond its limits, but it apparently does. I find this more than curious.

Either a large number of programmers and project managers have crap for brains, or we are being intentionally messed with, or converting display screen address touches and converting them to text is one of the most extremely complicated things a computer can ever do. It has to be one of those three, doesn’t it? What am I missing?

28 thoughts on “The math doesn’t work

  1. Try plugging a keyboard into your tablet and typing. It is fast, right? That means it is a problem with either the touchscreen hardware itself, or the driver.
    Point 1 – Hardware is almost always designed by people who don’t understand software.
    Point 2 – The touchscreen driver was probably written by the same people who designed the touchscreen hardware.

    I could dust off my ancient driver debugging skills and see why my tablet has the same problem, but I am more likely to just suck it up and hope for a better driver.

    • Hardware is almost always designed by people who don’t understand software.

      The converse is usually true too, right?

      • It may be that in some cases, the programmers don’t understand the hardware, AND the hardware engineers don;t understand programming, but this tablet was built by Apple – a combination hardware/software company.

        Don’t get wrong though; it is an amazing piece of engineering, materials technology, programming and all the rest and I am grateful to have the opportunity to own and use it. But like any technology it has its quirks. The man cussing at his automobile, who once rode a horse as his primary transportation, is an example of this. I’m that guy I guess, in a sense.

        • The people who designed the hardware within apple are probably not the same people who wrote the the software at apple.

  2. It’s an issue of priorities. The keyboard guys need the priority resources (both in programming and the machine’s resources itself.) The problem is, you can’t put “actually types when you hit the letters” on a feature list, so guys who want to sell the stupid thing on stupid features lists don’t see the value of prioritizing it. You can’t sell “shows letters on the screen when you type.”

    Well, wait. If you know what you are doing, you CAN, because Steve Jobs DID, with the “it just works” selling point. Responsive typing was part of the It Just Works thing. Steve knew how to sell it, and more importantly, he knew to demand it of his programmers. It actually WAS one of the key sticking points of releasing the iPad — it was in development LONGER than the iPhone, but Steve wouldn’t let them even demonstrate it until the typing and swiping delays were imperceivable, and wouldn’t let them upgrade the software until they were able to add new features AND keep the responsiveness.

    And then Steve died.

    • Actually, as someone who has to deal with the hell that is iPhone / iPad on a daily basis, that’s not exactly true.

      There is a 300ms delay between a finger down event and when a ‘click’ is accepted. This is a nightmare of amazing proportions trying to create responsive websites. The issue is “are you clicking or doing a swipe?” and the only way to do it is to wait a brief moment to see if the finger moves within milliseconds of the initial contact. I literally was working on this a hour ago.

      As for the keyboard, it shouldn’t be waiting at all – but I bet it is.

      • Except that Apple successfully implemented the semantics of a click being “touch and IMMEDIATELY release”. The magic thing is, the only way you can get user buy in on that interface is if it is ACTUALLY responsive. When the thing doesn’t respond as soon as you release, then the natural inclination is to either press again, or press longer (which breaks the semantics.) It’s a complete whole that doesn’t work when either part is missing.

          • Well, that depends. You said a finger-down event, which brings all its own problems. Doesn’t the API have a way to work on finger up instead? Otherwise, you’re trying to reinvent the wheel. Mouse-down has always been a problem, and almost everything happens on mouse-up. It has to be the same way with fingers.

        • And just so I’m clear and not sounding like an Apple Hater, every device has this issue in the web. Apple just happens to have that 300ms as a default.

      • Bingo.

        Making a keyboard respond quickly is trivial, IF all you can do to it is tap a key. But if you can do other things than tap a key, AND those things take time to do, then the keyboard driver has to wait that time to see what you ultimately did, and so devine what you intended. It cannot read your mind, rather it can only detect what you want from what you did, or what you didn’t. The more kinds of things you can do with a touch screen, and the longer you can take to do those things, then the slower the response will be to you doing them.

  3. ‘Way back in the early days of mainframe computers, the story is that the programmers had to slow down the response to keyboard input because users complained the machine was reading their minds by anticipating their input and displaying results before they had actually pressed a key. Perception is everything.

    Today, the new gee-whiz processor comes out and software bloats to suck up those extra cycles cuz there ain’t no reason to code efficiently like in the old days of limited cpu horsepower. I’m gonna go pull out my slide rule now.

      • Awesome! Now I need a digital surface noise generator/dynamic range compressor/bandwidth limiter to simulate LPs and 78s when playing my iPod, and my life will be complete. No; don’t tell me there’s already an ap for that… Hell I bet there is, complete with a video display of your stack of disks in an auto-changer, with lead-in and lead-out noises and graphics.

        • And it “skips” when your iPhone’s motion detector senses enough G-force. Even if you set it down on a table and dance on the floor, the floor vibrations would cause a skip. Remember that? Yeah; we need someone to spend five million dollars developing that simulator. It would make a profit too, no doubt.

          • I’m sure it already exists.

            If my experience is in any way still applicable (I used to work in close contact with an audiophile magazine) it probably cost $5,000 to develop, sells for $5,000,000 per copy, and plays mp3s under the graphics and filters.

            Oh, and you need to let it “warm up the speakers” before you play anything…

    • I had a text book (“The design of man-machine interfaces”, don’t remember the author, can’t find it on Amazon) that advocated this intentional slowing down thing. That caused me to toss the book and put the author on my “ignore this fool” list.
      Touch panels are tricky, because they have to respond to a whole bunch of different inputs. Since “touch and hold” has meaning distinct from “tap”, there are timers involved in telling the two apart. And if you don’t think things through exactly right, you end up with the sort of problem you mentioned.
      Apart from that, there is also the “virtual disease” — present day computers use vastly more resources for the same job than did machines in the 1960s and 1970s. Yes, they do more, too, but simple tasks are less efficient than they used to be, when counted in machine cycles. When counted in microseconds, you’re typically doing pretty well still. (Same sort of thing applies to memory use.)
      For example, back in 1975 I used a timesharing system (“PLATO”) which supported 600 graphics terminals, highly interactive, on a quad-CPU system with a 10 MHz CPU with 2 MB of main memory and 24 MB of secondary memory. Today’s programmers would have a hard time delivering such a result.

      • Today’s programmers would have a hard time believing it was possible. I wouldn’t. I used PLATO back then, too.

  4. There is also the whole “web/cloud-based” crap-ton of garbage with a lot of apps these days. You type, and for each letter it sends a packet off across the intertubes, things happen on a server somewhere, and it sends a response back which tells the computer to display something. I bump into that on a lot of web-based things, particularly those that have any sort of “predictive” technologies to make my life “better.”

  5. I’ll second the above comments, and add a couple of my own:
    1) If you’ve got an android tablet, most of what’s being done is running in a virtual machine environment — admittedly a compiled on, under Dalvik — that adds overhead. Pauses for garbage collection, etc, can be unpredictable and slow things down. Class this under the larger category of “computers spending resources to make things easier for the programmer”.
    2) I’d bet a large part of the pause for typing, specifically, is word prediction. Unlike typing a single letter, updating the list of predicted completions is computationally expensive. (Not very, mind you, if they did the algorithms correctly; but more than registering a single keypress).
    3) Typing is a pretty bursty activity; the processor is likely in its power-saving idle mode at the beginning of each keypress and processing is unlikely to last long enough to go into the full-speed or turbo modes, so you’re not getting the full power available, either.
    And finally…
    4) All that crap running in the background trying to report your GPS coordinates, bank balance, and pizza topping preference home to Big Brother is probably consuming a lot of cycles, too.

    I don’t actually know how hard it is to translate the screen touch into a keypress, but it’s definitely more than registering a physical key switch on a hardware keyboard.

    All that said, yeah, responsiveness to input could use some attention.

  6. OK, so essentially, I’m dealing with a Nutrimatic Drinks Dispenser from the Cyrus Cybernetics Corporation.

    As for the issue of dwell time as a means of determining intent; it’s a keyboard. It has a specific purpose. It also has a remove-keyboard-from-screen button, and therefore there need be no dwell time decision function at all other than the repeat function that a physical keyboard has. Touch it and it should generate and display the appropriate symbol. That shouldn’t take more than a single digit number of milliseconds, and even that extremely lengthy amount of time would not be strictly necessary except as a means of avoiding accidental doubling due to a light touch that might be interpreted as a double touch.

    If we go by the human “psycho acoustic” model of speech intelligibility in audio systems (I spent decades working in audio, do that’s what I often use as a reference) there is a 35 millisecond delay threshold, beyond which echoes, or multi path interference from separated speakers, etc., begins to reduce speech intelligibility. So in light of that, 35 milliseconds or less would likely be an acceptable delay, as that would probably be fairly near to the human brain response time. Even a very ho-hum computing device can do a hell of a lot in 35 milliseconds, and so there’s simply no excuse, says I.

    OK, I’ll try disabling the auto-correct function and see what happens. It’s as much a pain in the neck as it is a help anyway – much too Cyrus Cynernetics-ish. “Oh, you obviously want to say x.”
    “No, I want to say y”.
    “I don’t think so. My extensive statistical analysis says you very much want to say x.”
    “Go fucking hang yourself!”
    “Share and enjoy.”

    • 50 Internet points for the HGTTG reference.

      As for the keyboard, many of the ones I use daily have touch & hold capability to extend the keys. If the area of the ‘button’ is small, it’s hard to hit (especially with no tactile feedback), so they make them large. But then you lose the number of keys possible and have to revert to the touch & hold issue. Which introduces lag.

      This is why I love my Surface. I just plug in a regular keyboard and go to town.

      • Yes; the iPad has big enough “keys” but that means you have to toggle between three pages of keys to get all the characters.

        I’ll just have to break down and get a separate keyboard, which, from what I’m reading here in comments, will solve all my issues. I’ve been being stubborn on that point, for no particular reason.

        • I’ve found that the easiest way to solve this issues is to avoid doing anything on a mobile platform that involves typing more than a few words. I’m not going to carry a keyboard around with me to use with my tablet or phone. I’ll carry a laptop if I intend to work. If it can’t be said in a few words, it can wait until I get home, where I have many very friendly and clicky keyboards willing to take my input at human-friendly rates… so long as I close all my tabs in Firefox, anyway…

        • And elevators, which when working would arrive on your floor before you even realized you needed one, but they could become depressed and resort to sulking in basements. Robots too, or rather: “Your plastic pal who’s fun to be with”.

    • Yes, clearly a keyboard function doesn’t want to obey all the delayed actions rules of the general touchpad. That leaves a couple of possibilities. Perhaps the API doesn’t support the fast action operations a keyboard wants. Or it does, but the programmer is too dumb to know about them and use them. Or it’s some other overhead, like the word prediction or on the fly spell checking that others have mentioned.
      I suspect it’s one of the first two; my laptop does #3 in various places and they don’t cause delays — modern computers are plenty fast to do that sort of thing in a small enough number of milliseconds that you don’t see delays there.

  7. Well, Facebook and the phone companies presumably found a way to monetize seething customer hatred. Maybe screwing us on typing speed makes them a hundreth of a penny. Certainly websites like to slow down whenever advertisements are visible; I can imagine a OS maker getting paid to make typing slower when certain ads are up.

Comments are closed.