The flicker issue and jerky graphics on the Windows operating system has been an issue for a while. I have been able to track down one possible issue that might be happening, but I don’t know how (or if) this can be changed in a graphic Xojo program on Windows. Below is a picture that will help me explain what I believe I am seeing on Windows and OS X when drawing graphics. I am just using microseconds as a unit of time, and this will help me explain my thoughts:
Lets say that a picture is to be drawn in a Xojo Control, it can be a canvas, the Window, or OpenGL, as it seems to happen on all on the Windows OS. If the graphic is to be refreshed once every microsecond, then the OSX implementation of graphics works well with smooth graphics, as the counter would fire once every microsecond and the time between each firing would also be one microsecond. In Windows with Xojo, I believe that I am observing that the number of times the graphic is being updated is the same, where the graphic is updated 6 times in 6 microseconds, but the time between the firing of each of these updates is different in Xojo.
Windows is able to have exceptionally high updates (frames per second counter), and I am noticing that the time between each graphic update causes the flickering or studdering of graphics being refreshed (frequency). I have been working with many declares to try and minimize the time difference between each refresh, but have not been successful.
I am not sure if there is an answer to this question, and is there a way to have both a consistent counter and frequency in Xojo with Windows with high performance graphic applications? This may be one of those questions where someone has a solution that happens in the middle-of-the-night
After creating a few programs and testing, the Thread:Timer pair will give reasonable counter:frequencies for video. Its not perfect, and its good enough
I think that slowing the refreshes help the issue, but doesn’t remove the issue. One thought is that slowing the number of refreshes down will allow more computer cycles to complete the calculations and render graphics to the screen. I was playing with different ways to force drawing (glFlush, etc.) and this sometimes helps and sometimes makes it worse. When I slowed down the rendering speed slightly and then forced drawing, then the flickering and stuttering didn’t seem as bad, and there was still flickering.
As long as the refreshes are just barely faster than about 60 frames per second which is higher than the human eye flicker rate, then
the graphics seem to be ok. When I was trying to go faster than this then the flickering seemed more severe. The time difference between 1.0 to 1.5 microseconds is 50%, and the time difference between 5.0 to 7.0 microseconds is 40% which may make the flicker seem less.
One of the parts with graphics is that there is always an issue with the forcing the commands from the graphics pipe as the graphics look great as long as the pipe is being emptied, but once the pipe is empty then there is a lag time to refill the pipe, which might look like flickering.
I would be nice to have rendering at high rates so that the human eye couldn’t detect the flickering, and I am trying to the best drawing animation refreshes with the speeds that I have. Fine-tuning the refresh rates with the thread:timer pair helps, but the slow refreshes of the timer can be a hindrance.
Hi Tim. A consistent 60 fps would be great. Below is a link to a YouTube clip that I made with a Height Map. Almost all textures and pictures are first loaded into the computers memory and are rendered around 20 fps, and when I stop moving the camera, I get some fps rates of up to 120 fps.
Hi Christian. I am able to get FPS rates of up to about 2300 fps (I know, its a silly high rate) when there is a very light load. This FPS rate happens when all the data is loaded into memory and pushes the data to the memory card. Going from memory to memory is very fast. The 1 ms consistency is nice, and this seems to be a load issue (maybe?).
