> If it notices that the driver's head has turned, it adjusts the HUD elements being projected in less than 300 milliseconds to compensate. It is very slow. P

> If it notices that the driver's head has turned, it adjusts the HUD elements being projected in less than 300 milliseconds to compensate. It is very slow. People feel discomfort when different "overlays" lag by as little as few tens of milliseconds. People feel uncomfortable working with touchscreens because they feel "unnatural" when they push the button, and it only reacts, and plays animation half a second later. What people say what feels most "fake" about touchscreens is stuttering, and lagginess. I believe you really need to go to sub-millisecond levels of latency for it to feel "glued" to the real world. I had a touchscreen project in the musical instrument space, with a pressure sensitive touchscreen, where button animation had to match the touchscreen pressure. Even with all tricks, lag on Android was making it completely unusable, not to say Android's audio API is completely not suited for serious audio work. In the end we went bare metal with it. The lowest latency we got was 18ms by using the touchscreen interrupt to set the sensor value as a pointer to bitmap image of a button animation frame. Yet, some more experienced musicians said that it was still "felt off." I'm thinking to go full FPGA next time I need to do any latency sensitive HMI with kinetic-screen interaction.