(Possibly SDL2-only. If so, it only applies after #71 is merged into master.)
When running some of the SDL graphics tests under WSL (Ubuntu) with Xming, they run in slow motion (microscopic delta times) at extreme frame rates while being very unresponsive. Every few seconds, there is a skip (huge delta time), where any pending input events are also handled.
Theory: SDL_RenderPresent() does not flush the rendering command queue, and page flipping either does not work, or retrace sync is not relayed back to the application, and as a result, the application runs at insanely high frame rates just issuing commands, that are then executed with a huge delay.
It appears to be less of a problem when using the Surface API and SDL_UpdateWindowSurface(), though that's likely just because the software rendering slows the script down, so it doesn't run as much ahead of the X server/driver.
(Possibly SDL2-only. If so, it only applies after #71 is merged into master.)
When running some of the SDL graphics tests under WSL (Ubuntu) with Xming, they run in slow motion (microscopic delta times) at extreme frame rates while being very unresponsive. Every few seconds, there is a skip (huge delta time), where any pending input events are also handled.
Theory: SDL_RenderPresent() does not flush the rendering command queue, and page flipping either does not work, or retrace sync is not relayed back to the application, and as a result, the application runs at insanely high frame rates just issuing commands, that are then executed with a huge delay.
It appears to be less of a problem when using the Surface API and SDL_UpdateWindowSurface(), though that's likely just because the software rendering slows the script down, so it doesn't run as much ahead of the X server/driver.