Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This lag is in the software stack (mostly in UI graphics). Not in hardware.

Remember Androids ~>200ms sound lag?



What I've read is most of the lag in the more optimized touchscreen stacks (read=iOS) is due to filtering and smoothing, which takes a few samples to do. The worse stacks (early android) had poor drivers and a lot of layers of abstraction, or worse, Java (maybe this is what you mean when you say "UI Graphics", but the raw numbers we're talking about here are on a far lower layer than scrolling in lists).

Graphics rendering lag is at worst 2 frames of video (double-buffering).


Definitely not. Most of mobile software strives to run at 60fps. That's just 16.7ms.


display animation at 60fps and react to a hardware input through layers and layers of software abstraction are two different things.

Run of the mill 3M controller has 5ms latency

http://datasheet.octopart.com/87-5961-211-3M-datasheet-21189...

5 year old Fujitsu FMA1127 had 10ms.

http://www.fujitsu.com/downloads/MICRO/fme/tsc/FMA1127_Data_...

Interrupt latency is measured in nano seconds.


If you had read the PDF, 5ms is the "minimum touch time", which is not latency, but a minimum touch time it can register.

The same software has no problem rendering complex games and doing all kinds of game logic, all in 16.7ms. What makes you think asking for a touch input will take 15 times longer?


Actually its response time.

I already gave you an example of software stack impact on latency - Android sound lag went down from >250ms to respectable 10ms for some Nexus devices. Blame buffers.


> Actually its response time.

Actually, no, it isn't.


"This controller is well known for its < 5.4 milliseconds response time"




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: