[PATCH weston] Make backends always specify output repaint time

[Daniel Stone]

Hi,

On 8 April 2013 22:11, Kristian Høgsberg <hoegsberg at gmail.com> wrote:
> The problem that Pekka brought up of not sending the right timestamp
> is still not really fixable with the above structure.  When the
> compositor repaints and sends out frame events it still doesn't know
> when the frame is going to be visible.  We could send out frame events
> when the pageflip happens, but then we've used up precious time in the
> repaint cycle.  Or we could send out the frame event and then a new
> "this is the timestamp when your content was actually presented", but
> I don't really think it helps clients at that point.  They need to
> start rendering the next frame as soon as possible, but we simply
> don't know the timestamp at that time.  When we do know the timestamp,
> it's too late.

Not really, they're two totally orthogonal (and sometimes
complementary) usecases.  The frame event is just about driving
animation clocks at a rate near constant with the presentation rate.
The presentation timestamp is separate to this, but useful in its own
right.  Imagine a media framework, for instance: you want to drive the
master clock off the frame timestamps to make sure your throughput is
always as much as the compositor can push, but then you also want to
use the actual presentation timestamp for A/V sync, so you can get
each frame as closely synchronised as possible.

The two are just related enough to be almost-but-not-actually useful
for the other's usecase.

Cheers,
Daniel