flood's input lag measurements

[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

[flood]

https://docs.google.com/spreadsheets/d/ ... sp=sharing

[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

[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).

[flood]

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

[spacediver]

...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).

[flood]

...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.

[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.

[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)

[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.