02-18-2025, 05:47 PM
Not a single part of SCREEN 0 in QB64 is hardware accelerated. The video mode is entirely emulated in software, and the final "rendered" frame is handed over to OpenGL.
Most of us design our SCREEN 0 applications using a "game loop" style. In this approach, events/input are handled, and the entire screen is cleared and redrawn at a fixed number of frames/second. While this method works well for applications that need constant refreshing, it's not ideal for maintaining thermal and power efficiency. One could dynamically adjust the _LIMIT in the main loop to reduce unnecessary redraws, but you might still end up redrawing the whole screen more than necessary.
For a SCREEN 0 TUI application, my idea is to design a retained-mode TUI framework. This approach updates the screen, or just parts of it, only when they are "dirty" – essentially when they need to be repainted. Each GUI object can trigger a "repaint" event when needed. This method can be further optimized by culling objects that are not visible. A z-order for every GUI object can be used to determine the object stack.
Most of us design our SCREEN 0 applications using a "game loop" style. In this approach, events/input are handled, and the entire screen is cleared and redrawn at a fixed number of frames/second. While this method works well for applications that need constant refreshing, it's not ideal for maintaining thermal and power efficiency. One could dynamically adjust the _LIMIT in the main loop to reduce unnecessary redraws, but you might still end up redrawing the whole screen more than necessary.
For a SCREEN 0 TUI application, my idea is to design a retained-mode TUI framework. This approach updates the screen, or just parts of it, only when they are "dirty" – essentially when they need to be repainted. Each GUI object can trigger a "repaint" event when needed. This method can be further optimized by culling objects that are not visible. A z-order for every GUI object can be used to determine the object stack.