screen mouse loopback

This describes an additional function in my reaction speed test program. You can find it here.

When I tested my reaction sped test program on my notebook and my regular PC I first suspected a timing bug when I always achieved ~20ms better results on my notebook. But then it showed up that I get the same slower results when I plug my TFT as an external monitor to my notebook. The next step to substantiate my suspicion about a laggy monitor was to start an audio editing software on my notebook that displays a fast increasing counter during playback. External TFT and notebook display show the same screen. I filmed both displays 'simultanously' showing the counter with my video camera. The single frame on the left that I cutted out of the taped sequence shows a counter on the monitor that is 40ms behind the counter on the notebook display! But these 40ms are an extreme value, because the counter only has a resolution of 40ms. In the taped sequence are a lot of frames where is no time difference visible and others showing these 40ms. The truth is somewhere inbetween. It seems that the TFT is buffering at least one frame (~17ms@60Hz) for whatever purpose before it displays it.

Meanwhile I created a small program that displays on every frame the elapsed time in ms since program start (modulo 1000ms). It writes that time running from top to bottom to avoid blurring, and it writes it two times, white and black on gray, to account for different rise/fall times. Clearly the display on the larger monitor is one frame (17ms) behind. On the fading numbers one can estimate the rise/fall times of the LCD. Camera exposure time was 8ms.

Because I thought it might be of common interest I decided to add a feature to my program that can measure the overall delay of the system.
To activate it select the appropriate button in the menu.
If this measurement turns out to be correct, you can substract the result from the value you get with the reaction speed test to have really your own reactime time. This test could be used to compare whole computer systems for their intrinsic lag and of course to compare displays and their apparent delay time.

This window will appear when you start the test. The hopefully clever way to test the round trip delay is to move a random pattern on the screen and to show it to an optical mouse as if it was the surface of your table. The large square in the middle is the pattern that shifts in x and y. The small square in the upper right corner is for visual feedback, it moves if the mouse is correctly placed and can see something. I do not expect that this technique works on CRT screens because 1) the thick glass between front surface and phosphor leads to total defocussing and 2) the flickering inpersistent nature of CRT images.

You must hold the mouse upright and with 2..3mm distance to the screen - no joke! It works fairly well with my Logitech MX510 mouse and most probably with all mice containing the newest chip generation that can be recognised by '6400 fps' or '5.4 Mpixels/s' statements on the package. Inside these mice is the ADNS3060 chip from Agilent that works a lot better for this purpose than the one in my older Logitech mouse. You have to experiment with the distance to the screen. The defocussing is needed to blur the fixed RGB pattern of the display, otherwise the chip cannot detect a motion. But if you go to far away the moving pattern is also blured too much. It helps a lot to cover the bright light source underneath the mouse with some opaque tape.
I recommend plugging TWO MICE onto your PC while experimenting with this! Use one mouse for operating windows and the other one for the science.

The result is displayed in the same window as the reaction speed test is. It doesn't matter too much if the curves of predefined path and mouse feedback diverge a lot more than in reaction test mode. Because of its stability the calculation is in this case done with a cross correlation.

results:

1600x1200
notebook Inspiron 8200- WinXPHome - internal display
vsync on: 56ms
vsync off: 36ms

external Dell2001FP monitor
vsync on: 76ms
vsync off: 55ms

average PC - Geforce4 - WinXPPro - Dell2001FP monitor
vsync on: 76ms

1280x1024
notebook Inspiron 8200 - WinXPHome - internal display
vsync on: 55ms
vsync off: 33ms

external Dell2001FP monitor
vsync on: 75ms
vsync off: 51ms

external LG Flatron 1810 monitor
vsync on: 60ms
vsync off: 38ms

average PC - Geforce1 - Win2k - LG Flatron 1810 monitor
vsync on: 44ms
vsync off: 35ms

Send your results and comments to:

Please excuse if it takes a few days to answer the mail.

The program is no visual gem, is not finished and most probably contains bugs!

2005/03/26


This describes an additional function in my reaction speed test program. You can find it here.
	When I tested my reaction sped test program on my notebook and my regular PC I first suspected a timing bug when I always achieved ~20ms better results on my notebook. But then it showed up that I get the same slower results when I plug my TFT as an external monitor to my notebook. The next step to substantiate my suspicion about a laggy monitor was to start an audio editing software on my notebook that displays a fast increasing counter during playback. External TFT and notebook display show the same screen. I filmed both displays 'simultanously' showing the counter with my video camera. The single frame on the left that I cutted out of the taped sequence shows a counter on the monitor that is 40ms behind the counter on the notebook display! But these 40ms are an extreme value, because the counter only has a resolution of 40ms. In the taped sequence are a lot of frames where is no time difference visible and others showing these 40ms. The truth is somewhere inbetween. It seems that the TFT is buffering at least one frame (~17ms@60Hz) for whatever purpose before it displays it.
	Meanwhile I created a small program that displays on every frame the elapsed time in ms since program start (modulo 1000ms). It writes that time running from top to bottom to avoid blurring, and it writes it two times, white and black on gray, to account for different rise/fall times. Clearly the display on the larger monitor is one frame (17ms) behind. On the fading numbers one can estimate the rise/fall times of the LCD. Camera exposure time was 8ms.
	Because I thought it might be of common interest I decided to add a feature to my program that can measure the overall delay of the system. To activate it select the appropriate button in the menu. If this measurement turns out to be correct, you can substract the result from the value you get with the reaction speed test to have really your own reactime time. This test could be used to compare whole computer systems for their intrinsic lag and of course to compare displays and their apparent delay time.
	This window will appear when you start the test. The hopefully clever way to test the round trip delay is to move a random pattern on the screen and to show it to an optical mouse as if it was the surface of your table. The large square in the middle is the pattern that shifts in x and y. The small square in the upper right corner is for visual feedback, it moves if the mouse is correctly placed and can see something. I do not expect that this technique works on CRT screens because 1) the thick glass between front surface and phosphor leads to total defocussing and 2) the flickering inpersistent nature of CRT images.
	You must hold the mouse upright and with 2..3mm distance to the screen - no joke! It works fairly well with my Logitech MX510 mouse and most probably with all mice containing the newest chip generation that can be recognised by '6400 fps' or '5.4 Mpixels/s' statements on the package. Inside these mice is the ADNS3060 chip from Agilent that works a lot better for this purpose than the one in my older Logitech mouse. You have to experiment with the distance to the screen. The defocussing is needed to blur the fixed RGB pattern of the display, otherwise the chip cannot detect a motion. But if you go to far away the moving pattern is also blured too much. It helps a lot to cover the bright light source underneath the mouse with some opaque tape. I recommend plugging TWO MICE onto your PC while experimenting with this! Use one mouse for operating windows and the other one for the science.
	The result is displayed in the same window as the reaction speed test is. It doesn't matter too much if the curves of predefined path and mouse feedback diverge a lot more than in reaction test mode. Because of its stability the calculation is in this case done with a cross correlation.
results: 1600x1200 notebook Inspiron 8200- WinXPHome - internal display vsync on: 56ms vsync off: 36ms external Dell2001FP monitor vsync on: 76ms vsync off: 55ms average PC - Geforce4 - WinXPPro - Dell2001FP monitor vsync on: 76ms 1280x1024 notebook Inspiron 8200 - WinXPHome - internal display vsync on: 55ms vsync off: 33ms external Dell2001FP monitor vsync on: 75ms vsync off: 51ms external LG Flatron 1810 monitor vsync on: 60ms vsync off: 38ms average PC - Geforce1 - Win2k - LG Flatron 1810 monitor vsync on: 44ms vsync off: 35ms