11-19-2023, 02:59 AM
An important thing to understand is that `_Display` does not actually update what is drawn in the window, rather it renders a frame of the program and then queues that frame to be drawn on the next display refresh (this is how it can get away with not pausing execution of the program and still ensure no screen tearing). The queue itself is effectively 2 frames deep.
The display refresh happens at 60fps* and the program is synced to draw the frames at that rate, but there is no perfect way to call `_Display` the right number of times to ensure there's always one frame in the queue when the display refresh happens. `_Limit 60` or faster is close, but you're still going to get either some moments where the queue was empty when drawing the screen, or moments where the queue drops a frame due to becoming full, and those situations cause the stutter.
We could definitely provide a command that waits for the next frame to actually be drawn on the screen (without going into too much explanation, that `Wait` you're doing is emulated and doesn't do that properly). I just tried it out a very crude solution to make `_Display` do the waiting and was able to get an extremely smooth result at exactly 60 FPS, so that's promising at least.
* Supposed to happen at 60 FPS, I am also noticing it actually happens at 55.6 FPS like you mentioned. It looks like the timer function that is supposed to trigger the redraw at 60FPS is doing the calculation incorrectly, resulting in it being slightly slow. I'll make a bug report about this. Funny enough, the code that does the `Wait` you're using has a similar bug, causing it to also be slow.
The display refresh happens at 60fps* and the program is synced to draw the frames at that rate, but there is no perfect way to call `_Display` the right number of times to ensure there's always one frame in the queue when the display refresh happens. `_Limit 60` or faster is close, but you're still going to get either some moments where the queue was empty when drawing the screen, or moments where the queue drops a frame due to becoming full, and those situations cause the stutter.
We could definitely provide a command that waits for the next frame to actually be drawn on the screen (without going into too much explanation, that `Wait` you're doing is emulated and doesn't do that properly). I just tried it out a very crude solution to make `_Display` do the waiting and was able to get an extremely smooth result at exactly 60 FPS, so that's promising at least.
* Supposed to happen at 60 FPS, I am also noticing it actually happens at 55.6 FPS like you mentioned. It looks like the timer function that is supposed to trigger the redraw at 60FPS is doing the calculation incorrectly, resulting in it being slightly slow. I'll make a bug report about this. Funny enough, the code that does the `Wait` you're using has a similar bug, causing it to also be slow.