Hacker News new | past | comments | ask | show | jobs | submit login

To get an idea of the impact and importance of touch latency, see this intriguing demo by the Microsoft Applied Sciences Group: https://youtube.com/watch?v=vOvQCPLkPt4.

Drawing is one of those things that has felt awful on iOS devices to me.




Yep. There's a decent homebrew paint app on the Nintendo DS that runs circles around the smartphone counterparts... The Ds has a joke of a processor, terrible resolution, and no memory worth mentioning. But it has a resistive pressure-sensitive touchscreen and a stylus. That's enough to make a huge difference. Resistive touchscreens are fast and pressure sensitive, allowing far better conditions for art.


The sad thing is that official games aren't allowed to support the pressure-sensitivity provided by the DS hardware, so it's only used in homebrew apps like the paint app you mentioned.


Do you know why that is? For example, does the pressure-sensitivy vary wildly between individual screens?


Incredibly so. Calibrating the aforementioned paint app is a huge bitch. But it's great afterwards.


I remember reading somewhere that the DS homebrew "pressure sensitivity" was merely a hack. Since you hit more neighboring pixels when you push the stylus down, you get more "pressure". (This could be outdated information, though.)


>Drawing is one of those things that has felt awful on iOS devices to me.

Compared to what, since, according to TFA they have the smallest touch latency?

Perhaps you haven't tried the right apps. Most drawing apps (including major names, like Autodesk's) have slow-ass drawing code. Heck, some painting apps are even slow on my iMac (Corel Painter, ArtRage).

That's not because of "touch latency" though. It's because of slow draw engines. And I say that, because I've seen apps with very fast responsiveness.

Try Procreate ( http://procreate.si/ ), which uses the fastest engine I've seen (specially coded in OpenGL and 3D-accelerated). And check the artwork created with it by some of the community users (there are 2-3 videos on their site it's AMAZING).

Two other apps I found fast (but not as fast) are: Ideas, by Adobe, and Paper.


    Compared to what
Paper, dude(tte)! The analogue, lowercase-letter kind. :)

Paper and Procreate are excellent apps, but the input lag is very noticeable on my iPad 3; if you move your finger really fast and stop, you can see that it takes a short amount of time, before the drawn line catches your finger.

It wasn't long ago that dead-tree books were preferable to tablets, before Retina was a thing. And you could still argue print books are preferable.

Sometimes, the best Technology can achieve is the bar set by the non-digital world, and until then, it's going to feel grating to pedantic curmudgeons like yours truly. :)

+++

EDIT: A closing thought. The highest bar is always human perception:

(1) The optimal FPS for a videogame is, to my knowledge, 60.

(2) The optimal display resolution for a reading device is, TMK, ~326 PPI (Retina).

That is the goal. Anything lower than that will stick out and annoy people like me. Anything higher is not for the engineers, but the marketing department.


The "catches your finger" thing may be input lag, but it much more often is amateur level coding, it seems to me.

One of the first things you learn if you try to do a simple drawing app on a slow machine (think Commodore 64 or similar early 80's 1-2MHz computer), is that if you try to process every position change, you will lag badly.

First rule of doing a decent paint app, is to decide how large deltas you can accept between each position where you actually draw, and drop events accordingly. Small delta, and you will lag; high deltas and you either need to draw lines or will get "dots" instead of a continuous line, but your lag will be limited to that of the input device. Even an early 80's home computer can give you "lag free" painting this way, at the expense of precision if you do large, very fast movements over the screen.

This is "paint app writing 101". Yet a lesson that seems to have been lost on most people writing paint apps these days, possibly because they've become accustomed to computers fast enough that they're no longer constrained by it.

I don't know about iOS, but I do know from observation that out of 30+ draw/paint apps I've tried on Android while trying to find one I'd actually be happy to use (I did not find any; I'm picky), it is obvious that this is the problem for the vast majority of them for the simple reason that there's a huge spread in observable lag for them, and so even if we assume the fastest of them are limited by input lag, the extent of the lag on the majority of them will then still be down to crappy coding.

(the quality of paint apps for Android is just beyond awful in general; don't know about iOS)


60 fps isn't optimal - 120hz displays have a small but noticeable benefit when the rest of the hardware is good enough to lock in 120 fps.


have you tried the microsoft surface pro?


Nope - I haven't even seen one!


As much as I love my iOS devices, they still have MASSIVE latency compared to my Wacom tablet. There's just no comparison. I guess the touch processing had a lot of overhead.


Touch processing adds somewhere in the ballpark of 15-45ms of latency depending on the technology used in the screen and the quality of filtering in the touch controller. Anything about ~20ms of latency (total from touch to display) is perceivable by humans, is usually a good approximation for noticable increases or decreases in latency (i.e. shaving off 2ms doesn't really matter, but shaving off 15-20 will be noticeable).


Same here. My 21UX is staggeringly more responsive, and I expect the newer ones are better still.


No, they use different technology for touch registration.

(And, for what is worth, older Wacom tablets were also slow).


> Compared to what, since, according to TFA they have the smallest touch latency?

Drawing apps can easily end up with significantly higher latency than the baseline if they aren't careful with how they do input smoothing and such. It's really easy to get that wrong and bloat your touch latency.


I've done some research which involved the perceptual effects of latency, so I was interested in the test rig from their video and found a paper they published in ACM about it: http://edgey.com/wp-content/uploads/2013/01/p453-ng.pdf

Turns out that to achieve this 1ms latency system (once you have that, it's simple to add artificial latency) they had an FPGA directly processing touch data from a resistive sensor over a 2 MBps serial (optical) connection, computing the center of mass and directly driving a DLP projection display so that parallax between the surface being touched and the display would be eliminated. Nice rig!


That video was a great. Thanks for sharing it.


It's one of my favourite technology videos/demos of all time.

Every time someone criticizes Microsoft, I remember this video, knowing Microsoft's failures aren't for lack of talent.


Sadly, Microsoft's research group and just about everyone else at Microsoft aren't the same people at all :\


Of course the video is a little bit misleading when it talks about 1ms refresh, since touch response stops being the limiting factor before that point. AFAIK the fastest refresh rate for any phone on the market is 250Hz. That's 4ms refresh, which is great, but of course you also have to factor in time to actually process the touch event, change the image, and render it.


It's not misleading at all. They specifically said it was a test setup and stated that their aim is to be at around 1ms latency in the next decade. Obviously that means working on the other limiting factors to get there as well. It's not like they'll just try to get the touch response to 1ms and ignore screen refresh rates.


If we want a 60Hz app, the touch latency + processing + display shouldn't exceed 16.7ms.

1ms touch latency would be nice indeed, but I think 5-8ms would work just as well on most devices.




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

Search: