A different way to handle pulse timing

[John Hendrikx]

On 5/08/2013 20:46, Richard Bair wrote:
>>> As I wrote in the previous email, it seems that we currently are not blocked waiting for vsync(), at least on Windows with D3D pipeline. Anyway, even if we "fix" that, what you propose is that sometimes both threads will be blocked (the render thread waiting for vsync, the event thread waiting for the render thread), which doesn't sound perfect.
>> Right. That stinks.
> So today, the FX thread will block waiting for the render thread at the point where we synchronize state between the FX thread and render thread. The problem with this proposal is that we will wait here much longer waiting for vsync in the case that we have animations happening, which is just dead time when we ought to be preparing the next frame.
>
> Richard
Reading all this I get the distinct feeling that the current way of 
doing things is 'double buffering', where you have to wait until vsync 
arrives before you can start with the next frame, while you are looking 
for 'triple buffering', which allows a new frame to be prepared in a 
seperate buffer/graph/layout while the first (finished) 
buffer/graph/layout waits to be passed off to the render thread when 
vsync arrives.

--John