One additional important requisite:

New Emulator Latency/Jitter Rule:
Prevent GPU Power Management Between Frames
Try not to let a GPU idle for a full millisecond between graphics API calls (drawing or presentation)

This is due to power management. GPUs can go into idle mode (0Mhz-like operation) between frames if the GPU utilization is abysmally low. It is also why I discovered my beamracing demos failed if there was more than about ~1-2ms between raster events, and in debugging this problem during beam racing -- this was why. So I have to be creative (find reasons to do extra raster events within 1ms of each other, or just simply spread out those draw calls).

If you must let GPU idle, wake up at least a few milliseconds prior (configurable -- 1ms to 8ms) and "thrash" the GPU continually until your precision event (e.g. low-lag VSYNC frame presentation, or beamraced frameslice presentation). Using a waitable swapchain can also be a workaround partially because the GPU does precision wakeups during the VSYNC, especially due to the Windows desktop compositor always occuring roughly around then. But then if you execute right after that wakeup, you're waiting until the NEXT refresh cycle. So if you're doing inputdelay algorithms, start thrashing the GPU a bit early, (such as dummy draw commands before executing emulation slice), so the GPU is woken up by the time you're finished executing your slice of emulation (like the 1ms DosBox approach).

Anyway, lots of ways to workflow your GPU to prevent the problematic GPU power management "sleeping between frames and being tardy at waking up" that often occurs with emulators with under 10% GPU workload.

Emulators that spread GPU rendering slowly (e.g. in 1ms time blocks or less), tends to have much lower jitter as a result. Coincidentally, that's also an additional factor why Dosbox latency suddenly dropped like a rock once they went to the 1ms surge-execute system, which also meant that it also coindidentally spread-out the GPU draw calls over a long period, preventing more aggressive levels of GPU power management.

This rule goes regardless of whether you're syncing to VSYNC (less jitter/stutter) or whether you're beamracing (e.g. WinUAE lagless vsync, or trying a rasterdemo with VSYNC OFF tearlines)