(Not sure if NaturalViolence's stuff is correct, I just decided to write an own explanation from scratch)
swap request = the game tells the hardware to display the contents of a picture buffer in RAM to the TV. (more precisely, the Video Interface gets told to read out the contents of an XFB and display it on the TV).
refresh rate = number of swap requests which the game is doing per second on real hardware. I.e. PAL games will use something like 50 Hz and NTSC something like 60 Hz.
VPS = number of swap requests which our emulated CPU is processing per second. If this the same as the refresh rate, our CPU runs at the same speed as real hardware.
FPS = number of frames drawn per second. This is the number of frames which is actually displayed to the screen (note that swap requests come from the CPU, but frame processing is done on the GPU).
For progressive scanning the FPS should equal the VPS (this is a sign that the GPU thread is fast enough to catch up with the swap requests,.i.e. if the CPU runs as fast as on real hardware and FPS = VPS we can say that the GPU runs at least as fast as on real hardware).
For interlaced scanning FPS should be half of VPS. This is because when a swap request only covers the upper framebuffer fields (like every second swap request does when using interlacing), Dolphin is just skipping it. In fact, Dolphin doesn't emulate interlacing at all right now, and instead just uses progressive scanning at half of the target VPS (it basically just processes every second swap request).
EDIT: I just realized that the stuff I said about interlacing is only partially true; in interlacing is where the VBeam hack is involved. If accurate VBeam emulation is disabled, what I said is true. Otherwise VPS equals FPS (we are still using progressive instead of interlaced scanning though).
swap request = the game tells the hardware to display the contents of a picture buffer in RAM to the TV. (more precisely, the Video Interface gets told to read out the contents of an XFB and display it on the TV).
refresh rate = number of swap requests which the game is doing per second on real hardware. I.e. PAL games will use something like 50 Hz and NTSC something like 60 Hz.
VPS = number of swap requests which our emulated CPU is processing per second. If this the same as the refresh rate, our CPU runs at the same speed as real hardware.
FPS = number of frames drawn per second. This is the number of frames which is actually displayed to the screen (note that swap requests come from the CPU, but frame processing is done on the GPU).
For progressive scanning the FPS should equal the VPS (this is a sign that the GPU thread is fast enough to catch up with the swap requests,.i.e. if the CPU runs as fast as on real hardware and FPS = VPS we can say that the GPU runs at least as fast as on real hardware).
For interlaced scanning FPS should be half of VPS. This is because when a swap request only covers the upper framebuffer fields (like every second swap request does when using interlacing), Dolphin is just skipping it. In fact, Dolphin doesn't emulate interlacing at all right now, and instead just uses progressive scanning at half of the target VPS (it basically just processes every second swap request).
EDIT: I just realized that the stuff I said about interlacing is only partially true; in interlacing is where the VBeam hack is involved. If accurate VBeam emulation is disabled, what I said is true. Otherwise VPS equals FPS (we are still using progressive instead of interlaced scanning though).