The 2 flip calls is a good idea, I think you're right about the blocking! I just have to get my program more efficient (it didn't run properly at 60 fps so I had it down to 30). I use pygame to present stimuli in an electrophysiological experiment, and I need to sync the appearance of the stimulus with the EEG recording.
cheers Matthias 2009/2/13 Brian Fisher <[email protected]>: > What if you do 2 flip calls and then maintain 60 fps (or whatever your > refresh rate is) from then on? > (I'm thinking that the second flip call will block until the first is done - > I think most drivers behave that way so they don't get too far ahead) > > > On Tue, Feb 10, 2009 at 2:22 AM, Matthias Treder > <[email protected]> wrote: >> >> Hi guys. >> There was a thread about this issue in 2007, with no obvious solution. >> I got the same problem so I hope somebody knows a way out (if any). >> The point is I want to know exactly when a flip is occuring. Naive >> code could look like this : >> >> .... do some drawing here .... >> pygame.display.flip() >> timestamp = pygame.time.get_ticks() >> >> With double buffering, the flip waits for the next screen refresh, but >> the program is not blocking and waiting for the flip (which is quite >> reasonable), it just goes on. This means, however, that get_ticks() >> will probably return before the actual flip happened. With my screen >> (60 Hz), there is thus an unpredictable error of 0 - 16.6 ms. >> Is there any way to get to know when the flip happened, or at least to >> reduce this error below 10ms or so? >> >> Thanks. >> Matthias
