Page 12 of 44

Re: flood's input lag measurements

Posted: 09 Dec 2014, 05:05
by flood
fucking java

Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
x1000

after a few seconds

something has a memory leak... probably the arduino program itself is fucked

Re: flood's input lag measurements

Posted: 09 Dec 2014, 05:50
by flood

Re: flood's input lag measurements

Posted: 09 Dec 2014, 08:36
by flood
posted a summary on esreality: http://esreality.com/post/2691945/micro ... surements/

i guess i'll continue to use this thread as sort of a blog and use the google doc for storing data and results. major results and updated will go in the threads' ops

anyway first thing to do tomorrow is to compare this entire against a high speed video. i feel that some measurements are higher than they should be because the some parts of the screen which first light up in response to the twitch doesnt trigger the photodiode until the crt is scanning a brighter part

Re: flood's input lag measurements

Posted: 09 Dec 2014, 13:53
by spacediver
that esreality post... A+ man, nice writeup, and looks like it generated a lot of interest :)

Also, was thinking: shouldn't it be possible to manually specify a vertical position in the raster at which a frame is drawn? If so, you could directly measure the measured lag as a function of tear position (I know you said that with your setup it doesn't matter, but would be nice to test).

Re: flood's input lag measurements

Posted: 09 Dec 2014, 16:42
by flood
spacediver wrote: Also, was thinking: shouldn't it be possible to manually specify a vertical position in the raster at which a frame is drawn? If so, you could directly measure the measured lag as a function of tear position (I know you said that with your setup it doesn't matter, but would be nice to test).
actually yea it sort of is, by syncing the arduino signals to monitor refresh rate. maybe resyncing every time a flash is seen. but you'd need high framerate (like at least 4x refresh rate); otherwise there aren't enough locations to update the screen.

if it works well, it could be useful for lcd's though as it would allow the photodiode to be placed close up to the screen

Re: flood's input lag measurements

Posted: 09 Dec 2014, 17:12
by spacediver
flood wrote:
spacediver wrote: ...but you'd need high framerate (like at least 4x refresh rate); otherwise there aren't enough locations to update the screen.
which is why a single white frame sandwiched by black frames is a really good test stimulus - you can get a ridiculous framerate with that :)

(but i do get the need to test ingame situations too).

Re: flood's input lag measurements

Posted: 09 Dec 2014, 17:29
by flood
spacediver wrote:
flood wrote:
spacediver wrote: ...but you'd need high framerate (like at least 4x refresh rate); otherwise there aren't enough locations to update the screen.
which is why a single white frame sandwiched by black frames is a really good test stimulus - you can get a ridiculous framerate with that :)
yup working on it.

Re: flood's input lag measurements

Posted: 09 Dec 2014, 19:37
by spacediver
another thing you could do, to get a sense of the precision of the system (photodiode + arduino, OS, etc.) is to set up a program to periodically draw a white frame every X frames, in VSYNC mode.

Then you can measure the variance of the period of these frames.

Re: flood's input lag measurements

Posted: 09 Dec 2014, 19:40
by flood
actually did that a few years ago, but using the computer's own timing to measure (clock_gettime in linux can get sub 0.1microsecond accuracy/precision)
it turned out to be a near perfect gaussian distribution centered at almost exactly16.67ms (back when i used a 60hz lcd)

Re: flood's input lag measurements

Posted: 09 Dec 2014, 19:55
by spacediver
yep, that's similar to what I did here: http://forums.blurbusters.com/viewtopic ... 110#p12144

but if you used the photodiode to do concurrent measurements, you could get an estimate of the photodiode's precision.