Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Double buffering can use lots of CPU time #32

Open
PluMGMK opened this issue Jan 19, 2025 · 0 comments
Open

Double buffering can use lots of CPU time #32

PluMGMK opened this issue Jan 19, 2025 · 0 comments

Comments

@PluMGMK
Copy link
Owner

PluMGMK commented Jan 19, 2025

When double buffering is enabled (the default), a high-priority event is scheduled DoubleBufRefreshRate times per second (default 60 Hz). This event runs swap_buffers, 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.

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.
  • [More ideas will appear here if I think of them]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant