Page 2 of 3

Re: Here's a real example of a 1000hz display... I think

Posted: 08 May 2014, 23:39
by Chief Blur Buster
jlafarga wrote:so what you mean by low persistency is that if you ran the display at say 120hz and flashed the cursor for 1ms your brain would interpret it as if though the cursor was 1 millimeter behind your finger ??? (if your finger was moving at 1 meter per second)
Yes. Assuming 1000Hz input reads (average input latency of 0.5ms) and 1ms flash (midpoint of flash would be 0.5ms ago, aka the midpoint of the nearly-negligible motion blur). Since 0.5ms+0.5ms equals 1ms, you're in the right ballpark.

There are multiple variables involved, other lag factors (e.g. software, display signal latency, etc) that can fudge this around, including human vision response, as well as whether or not the display adds latency in order to do strobing. It's fun to play with http://www.testufo.com/blackframes to study the latency-lowering effect of lower persistence.

Re: Here's a real example of a 1000hz display... I think

Posted: 08 May 2014, 23:45
by jlafarga
thats great, maybe we are not so far from having mobile devices with a perceived latency like the one they showed in the video, this would be awesome for using a stylus on a touchscreen. I have the feeling that maybe the researchers from the video knew nothing about low persistance and did get their rig running at 1000hz. The paper mentions the following people: paul dietz and albert ng, both of which I tried to get in touch but so far no luck.

Re: Here's a real example of a 1000hz display... I think

Posted: 09 May 2014, 01:37
by Chief Blur Buster
I've heard back. Paul Dietz already knew about the latency-lowering effects of lowering persistence, and, yes, their lab setup was running at incredibly high refresh rates (far higher than 1KHz, in fact).

That said, -- 1ms latency may not even be fast enough to eliminate 100% human-noticeable effects.
That's a 4 pixel lagbehind during 4000 pixels/sec finger movement.

That 1ms total-chain latency, from finger to photons hitting eyes. That's herculean, considering many weak links in the latency chain -- just look at my GSYNC Preview Part #2 for the horrendous amount of latency between input and output.

We, at Blur Busters, are simply fixated at the 1000Hz goal, simply because that's a big mountain to reach, and other industry people (Carmack, Abrash) have talked of that number theoretically/academically (e.g. Down The VR Rabbit Hole). Some researchers are already working with >1KHz refresh rates.

Re: Here's a real example of a 1000hz display... I think

Posted: 12 May 2014, 03:00
by flood
Chief Blur Buster wrote: That's a 4 pixel lagbehind during 4000 pixels/sec finger movement.
Probably noticeable under controlled circumstances e.g. stylus + dot at the touch location..

1ms is a good long term goal, but honestly I think that most people would be very happy even with 20ms lag in touch devices, given that currently ios devices have ~50ms lag and that android devices have ~100ms lag.

Re: Here's a real example of a 1000hz display... I think

Posted: 12 May 2014, 14:07
by jlafarga
the iphone 5/5s has about 55ms latency according to this:
http://www.macrumors.com/2013/09/21/iph ... ch-screen/
Also, the smallest perceptivePixel multitouch display (27" I think) has around 10ms latency, you can kinda tell by looking at this video:
http://www.youtube.com/watch?v=rs6rwKNqBww
It runs at 120hz and I would't be surprised if the next display they release runs at 240hz (for real).

Saludos everyone!
JLafarga

Re: Here's a real example of a 1000hz display... I think

Posted: 14 May 2014, 23:11
by flood
jlafarga wrote:the iphone 5/5s has about 55ms latency according to this:
http://www.macrumors.com/2013/09/21/iph ... ch-screen/
Also, the smallest perceptivePixel multitouch display (27" I think) has around 10ms latency, you can kinda tell by looking at this video:
http://www.youtube.com/watch?v=rs6rwKNqBww
It runs at 120hz and I would't be surprised if the next display they release runs at 240hz (for real).

Saludos everyone!
JLafarga
wow that display is f*ing awesome

now why can't apple and google do it?

Re: Here's a real example of a 1000hz display... I think

Posted: 15 May 2014, 14:49
by Chief Blur Buster
Battery life is an issue. Double the GPU power to keep up the framerate at 120fps@120Hz.

It would be great to have a 120Hz rolling-scan OLED for blurfree flickscrolling in handheld web browsers :D

Re: Here's a real example of a 1000hz display... I think

Posted: 17 May 2014, 22:20
by flood
Chief Blur Buster wrote:Battery life is an issue
That's the same thing people said about big screens
and about 1080p screens

but anyway, if 10ms latency becomes 20ms for 60hz, that's still a huge step from 50ms...

Re: Here's a real example of a 1000hz display... I think

Posted: 27 Jan 2015, 20:41
by thijs
where will it end? 100K hz? is it possible to have a still image at 0 fps? And only update the part of the screen where things change? (sorry for being off topic I guess), this is what PCoIP uses to reduce bandwidth (ye I know, totally different technology)

Re: Here's a real example of a 1000hz display... I think

Posted: 28 Jan 2015, 09:00
by fury
It'd be pretty neat to have 1000hz with 1ms response time. I wish mobile vendors would get a move on cranking up the refresh rate and lowering the motion blur. There's so much talk about how high the PPI is or how accurate the colors are, but it doesn't amount to much in the end if it all goes to hell when in motion. Even before I got spoiled by 120hz with ULMB, I couldn't help but notice the lag of the screen behind my finger and the motion blur as it scrolls. Most of the time I'm looking at my phone's screen, I'm scrolling or otherwise moving. Twitter, news, videos, games...

Though, it's one thing to show off a display that simply lights up pixels under the finger at a high rate of speed. It's surely quite a haul to make a complete touchscreen UI stack that has that kind of response time. The basic touch sensor input filtering, analyzing of the data to determine if a touch event occurred and where it moved to, conversion of that touch event into a UI action (tap, scroll, pinch), the application interprets the event (find the nearest tappable thing and tap it, or scroll or zoom the window), the graphics driver redraws, the panel refreshes. It's tricky, cause in some contexts where a double tap is a distinct action (like web browsing), it would have to wait a bit before acting on a single touch just in case a second touch comes in right afterwards for a double tap. So there's some delay inherent in the gathering of the input to generate the events.