When double buffering is enabled (the default), a high-priority event is scheduled DoubleBufRefreshRate times per second (default 60 Hz) every SwapBuffersInterval milliseconds (default 16 ms). This event runs swap_buffers (or VDD_SwapBuffers if VDDVBE.386 is loaded and functioning), which runs through the entire back and front buffer every frame, comparing their contents dword-by-dword. This doesn't cause any problems on my hardware (Core i7-4790K overclocked to 4.4 GHz), but sometimes it can cause non-responsiveness when multiple VMs are running in 386 Enhanced Mode (UPDATE: since be657e6 that isn't really an issue anymore for reasonable refresh rates).

Some ideas to reduce the CPU time:

• Maintain a bitmap of "dirty" banks, which would be updated every time set_bank_select is called, and/or the cursor moves. Then swap_buffers would only run through the banks identified by this bitmap, and clear it afterwards. When the screen is not updating, it would only need to check the bitmap, see it's all zeros and return, instead of having to check the entire framebuffer.
• Use MMX to transfer data to VRAM if available? I'm not sure, but this might make the data transfer more efficient on CPUs with a 64-bit data bus, and maybe using it for the framebuffer comparison (in system RAM) might speed things up as well. This would require moving the build system to a newer assembler, since MASM4 obviously knows nothing about MMX instructions or registers.
• [Added 14 June] When double-buffering code runs under VDDVBE.386, we could use some kind of pagemap for the back buffer and then the CPU could help us by marking pages as dirty as they are written. This is similar to the "dirty banks" idea above, but would only apply in 386 Enhanced Mode, and at a 4K rather than 64K granularity.
• [More ideas will appear here if I think of them]