And even then it's probably still not perfect since you're sending to a framebuffer instead of controlling the beam directly, which adds at minimum 1 frame of latency. (Unless there is a "real-time" way to send a picture over HDMI)
Super Mario World and many other SNES (and later) games spends two frames after a controller jump input sending unchanged frames on-screen, before showing a frame where the player is jumping (tested in slow-motion camera). Emulators (and possibly FPGAs) can use run-ahead to skip past one or more of these "no change" frames, reducing input latency to match or surpass console latency (https://github.com/higan-emu/emulation-articles/tree/master/...).
Another strategy is to delay polling input computing the next frame until the end of the previous frame being drawn (RetroArch frame delay). This does not rely on the game not responding immediately to controller input, but is more prone to dropping frames if your CPU gets occupied and can't run your emulator for a few milliseconds.
