MAMEWorld Forums - EmuChat

OK I realize this doesn't exactly address your situation because we're on such different hardware and have different purposes, but still it might be interesting just to track the data.

I wrote a very small program that tries to detect a keypress and update a window as quickly as possible in response. It can be run:

- In full screen or window
- With double-buffering disabled or enabled
- If double-buffering is enabled, with lock-to-vsync enabled or disabled
- If lock-to-vsync is enabled, with adaptive vsync enabled or disabled

Right now I just have an X11 version (for Linux), I haven't written the OS X version yet and I certainly haven't written the Windows version yet (Windows programming, ewww).

Anyway, whereas before I wrote that SDLmame appeared to have a 7 frame latency on my desktop Linux system, using my simple latency tester program got much better results. I was able to achieve a 1 - 3 frame latency. There are a few specific details:

- I notice that my caps lock LED takes more than 1 frame to fully illuminate (between 1 and 3 frames, typically 2). I start my latency count at the first visible illumination level (i.e. as soon as there is any illumination of the caps lock key, even if it's not completely illuminated yet)

- I notice that my ancient DELL LCD display (it's an old - circa 2008 or so - IPS or PVS or something) seems to take a few frames to fully ramp into a change. My program just alternates clearing the window to full black or full red in response to a key press, and when going from black to red, for example, it takes typically about 3 frames to go from a just barely pink version all the way to the full red version. So I see something like
- Caps lock light starts to illuminate
- Nothing for 1 - 2 frames
- Window goes pink for 1 frame
- Window goes redder for 1 frame
- Window goes fully red

- I also notice that when going from caps lock on to caps lock off, the window updates exactly at the same time as the caps lock LED turns off, and sometimes even before it does. I have no idea what is going on here - is it possible that the keyboard doesn't turn off the caps lock light until the operating system has already serviced the key press and then tells the keyboard to turn the light off? Not sure.

- On this particular Linux system, the crummy OpenGL drivers on this system don't support enabling or disabling swap-on-vsync ("vsync") or adaptive vsync, so I couldn't test those at all. I found that if my settings were double-buffering windowed or full-screen, or single-buffered full-screen, my program was limited to updating the screen at the display refresh rate (60 Hz). Only if my program were single-buffered in a window was it not locked to the screen refresh rate. At no point did I witness tearing.

Anyway, I am not sure how to explain the 1 - 2 frames between caps lock LED illumination and screen update. Is it input latency in the monitor? Latency in the keyboard driver? Latency in the OpenGL implementation? All three? Not sure, but I suspect that it's monitor input latency, not surprising on a pretty old DELL LCD monitor ...