Re: [pygame] recap: refresh rate and timing issues

[Matthias Treder <matthias4all@xxxxxxxxxxxxxx>]

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 <brian@xxxxxxxxxxxxxxxxxxx>:
> 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
> <matthias4all@xxxxxxxxxxxxxx> 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