Hi, First, there are some problems with this test code:
- The first ten framerates will be 0.0 due to what I consider a misfeature in the way pygame reports framerate; this drags down your average. Even if you ran at a nominal 60Hz, the highest reported framerate is going to be 54fps (wherefore, I'm somewhat confused that you say you got 60Hz on a different machine; perhaps you were running a bit faster; e.g. I see 62Hz a lot on certain machines). - Averaging the framerates is a bit problematic because that is a reciprocal measure. It is better to average the frame latencies and then reciprocate that to get the average framerate. - You're attempting to synchronize the framerate to 60Hz, this can cause aliasing issues since pygame is software-backed, not graphics backed, exactly. E.g., if your code is actually 59fps, then the fastest it can update will be 30fps. It would be better to not include the argument to `.tick(...)` at all. Which brings us to the main reason: - Setting millions of pixels is not a job for the CPU; it's a job for the graphics card. However, pygame runs on the CPU. As you observe, larger displays run slower. If you want good refresh-bound performance, you probably want to make a GL context and draw with that, without disabling VSync. This is, in fact, what glxgears does, which is why it's running at a reasonable framerate. Ian
