Alt+Enter is a de-facto standard shortcut in many applications to toggle between windowed and fullscreen mode. Works in many games too.
Let’s necro this… 
Got a new shiny phone so I can do high framerate recording.
My PC is an old i5-3570k@4GHZ with an nvidia GTX770 on win7 x64.
Monitor is LG 32gk850g.
Xbox one Gamepad in USB.
RA is using Exact Sync, Gsync is On.
Vulkan is using max swapchain 2 (supposed to be the fastest).
240fps recording (1 frame = 4.167ms)
FCEUMM runahead 1 in smb
glcore hard sync 7 5 6 5 8 8 9 7 6 7
6.8 = 28ms
no hard sync 7 7 5 7 7 9 6 7 7 7
6.9 = 29ms
vulkan 9 7 4 9 7 8 10 6 7 6
7.3 = 30ms
vulkan no shader 7 5 5 8 5 8 7 8 6 9
6.8 = 28ms
So, I guess the explanation for the lack of difference is I’m using gsync.
It’s recorded on the bottom of my LG monitor tested for 6.4ms lag (so worst lag case),
for the xbone gamepad in usb I see 6.9ms from a test.
That adds up nicely: 6.9 + 16.67 + 6.4 = 30ms average if you want to think like that. 
And I tried to check the Mame main core in RA, to see if it has 1 extra frame of lag or not vs stand-alone.
Test is Unibios boot settings menu (supposed to react in 1 frame in MAME), bottom of the monitor.
windowed (aero enabled):
MAME 6 10 10 10 7 12 10 10 10
9.4 = 39ms
RA 13 13 13 11 13 10 12 11 11 10
11.7 = 49ms
fullscreen:
MAME 7 7 7 8 10 7 4 8 9 5 10 8
7.5 = 31ms
RA (hard sync 0) 12 8 10 7 10 8 8 11 8 7
8.9 = 37ms
gl no hard sync 10 11 11 11 9 8 10 10 10 9
9.9 = 41ms
vulkan 10 10 11 10 11 11 10 8 10 8
9.9 = 41ms
So, remember it’s with G-sync too for both RA-MAME and stand-alone (except for the windowed tests), lowlatency enabled for both in mame.ini.
FCEUMM didn’t show a difference for hard sync 0 or nothing, so I would ignore the slight advantage for it enabled here.
+10ms of lag for RA it is then, something that could be improved in theory.
2 Likes
A bit more testing with FCEUMM and smb still. (run ahead 1 frame)
gsync frame delay 12 glcore 6 6 7 10 9 9 7 4 8 8
7.4 = 31ms
So, frame delay doesn’t seem to do much with gsync…
Now Testing with gsync turned off, 120hz vsync swap interval 2.
gsync off glcore (hard sync off) 20 22 21 19 20 19 20 23 18 19
20.1 = 84ms
gsync off glcore (hard sync 0 frame) 11 9 8 9 9 9 9 10 7 6
8.7 = 36ms
gsync off vulkan swapchain1 10 12 9 11 11 9 7 10 7 9
9.5 = 40ms
gsync off vulkan swapchain2 9 11 8 7 8 11 10 7 6 9
8.6 = 36ms
gsync off vulkan swapchain3 12 9 12 12 6 9 9 5 10 9
9.3 = 39ms
- outside of gsync, hard sync 0 with gl is working as intended
- vulkan is fine, 4ms is within a margin of error and it’s not using as much cpu power as gl hard sync does
- vulkan swapchain images setting doesn’t seem to do much (with nvidia drivers?)
- gsync seems faster than other standard sync methods, unless you go and add frame delay on top of standard vsync, but it gives a small gain for something a bit unreliable (can be game dependant, cpu intensive)
4 Likes
Did some more tests.
In short, d3d11 is similar to glcore and vulkan with gsync, around 30ms.
More surprising, in windowed mode, bottom of the screen, it’s on win7 aero is enabled, gsync enabled for fullscreen mode only, same fceumm smb run ahead 1 frame (to get a 1 frame minimal internal lag):
windowed glcore default 11 10 9 11 9 8 10 9 12 11
10 = 42ms
windowed hardsync 0 frame (in case it does anything for nvidia drivers) 7 12 8 8 8 9 10 8 11 11
9.2 = 38ms
windowed vulkan 9 12 7 9 9 10 9 10 9 7
9.1 = 38ms
Around 40ms while fullscreen without gsync was giving 84ms (probably triple buffering with default nvidia drivers settings)…
Aero isn’t so bad in the end, most probably because my default monitor refresh is 120hz (or gsync helping with screen composition).
3 Likes
So, it means that with my Gsync monitor, I don’t need Frame Delay ?
Yes, you can drop it back to 0.
1 Like
Something must have changed because Duke Nukem 3D on Beetle Saturn + gsync monitor felt way more laggy to me than the same game on my real Saturn + CRT. Although i am still on RA version 1.9.6.
I can’t measure the lag on the real machine. All i can say is that it didn’t feel as sluggish. I could feel the difference is what i’m saying and it was definently not a placebo.
I even tested the beetle emulator on a CRT monitor and it wasn’t much different than the gsync monitor, so the extra lag doesn’t seem to be from the screen.
I think the emulator is adding about 3 frames of lag on top of everything. Im basing this on Sonic Jam and EWJ2 vs the same games on Genesis with GenesisplusGX. All games have 1 frame of lag on GenesisplusGX but 3 or 4 frames on Beetle Saturn.
1 Like
Im not arguing the Saturn might have higher input lag than the Genesis. But the Saturn emulator definently has higher input lag than the real console.
Also, the input lag in the Mupen core seems to be on par with the real console. Some games have up to 4 frames of lag but others like Smash Bros have zero lag, which means the enulator doesn’t add any additional lag.
But i haven’t found a Saturn game that has less than 3 frames of lag on Beetle Saturn, which makes me think it adds that amount in all games no matter what.
This is exactly what I was thinking earlier today, I’m not sure the console has this amount of input lag. It would be a definitive way to tell the difference.
I am confused now, I thought vulkan was supposed to have the lowest input lag of all the video drivers? Your tests show GL is more responsive and DX11 is as well?
Weird.
it’s all very driver-dependent. vulkan and d3d11 are usually similar.
If you have have Vsync off in RetroArch with Vulkan, you don’t get proper frame pacing, so you need to leave it on. I don’t think there’s any benefit turning it off for other video drivers either. On Nvidia cards people recommend setting Vsync on globally in conjunction with Gsync, so that games never go above your refresh rate and tear (I usually leave in game Vsync on too unless that particular game has some issue with it on). However, doing that will disable fast forwarding in the D3D drivers in RA, so you can set the retroarch.exe profile to use “Application Controlled” to get around that. I’ve never seen recommendations for AMD hardware VRR settings, so not sure what’s best there.
Borderless window is usually bad for Gsync support too, since Nvidia’s windowed mode Gsync often doesn’t work right or at all. Exclusive or flip model fullscreen modes are the best with Nvidia hardware.
V-Sync is required in retroarch for proper VRR.
Note:
Keep V-Sync active in Settings -> “Video” , it won’t work with it disabled.
I don’t know if something changed since then. But vsync doesn’t have any negative effects with VRR since the display refresh rate is higher than the target FPS of the emulator. Well, at least with g-sync. I don’t know if freesync works differently, but with g-sync, vsync doesn’t add any latency whatsoever when FPS is lower than maximum display Hz and it protects against temporary tearing in case of FPS hiccups.
There’s really no reason to disable it. I haven’t dived into the source code of how RA uses vsync, but it wouldn’t surprise me if it’s used for correctly syncing video and audio and audio time stretching.
1 Like
Retroarch isn’t your average PC game, it does stuff in a particular way.
All your results are really suspicious, I assume frames are randomly skipped, be it on execution or video recording / media player next frame counting.
Frame delay being inoperative when using VRR is the only thing I noticed too.
This is entirely off-topic, but can you expand a bit on this latency difference that you have observed with Dark Souls 2? I’m playing that right now and I’m using Fullscreen + V-Sync OFF + Scanline Sync with RTSS to minimize latency. It’s working nicely so far, but now I’m wondering if there’s an even better way to shave off some extra frames. 
Speaking of your issues with the Vulkan driver in RA, ever since the bug with the RTSS layers got resolved in the last beta versions of the app (see here for further reference: https://github.com/libretro/RetroArch/issues/9668), I have not noticed any oddity with the frame pacing. That being said, I’m not using a VRR screen and I keep V-Sync active with RA, so it could be that there is still some inherent issue with Vulkan and variable refresh rate situations.
What OS/APIs are you using? I found that smallest input lag is possible on GNU/Linux in KMS/DRM mode, Vulkan video, max_swapchain=1, no vsync, ALSA audio with 32ms or smaller buffer.
I agree.There is just with poor performance using kms.In face lakka uses KMS,too