[Cogl] [PATCH 3/3] Add CoglFrameTimings

[Owen Taylor]

On Fri, 2013-01-25 at 14:36 +0000, Robert Bragg wrote:
> > It seems like the main issue we still have some disagreements about is
> > the g_get_monotonic_time() mapping, but I don't think this has to
> > block landing anything at this stage.
> >
> > Adding cogl_gst_frame_info_get_presentation_time() or
> > cogl_glib_frame_info_get_presentation_time() functions are two
> > potential solutions. Before the 1.14 release there is also even the
> > possibility of committing to stricter time line guarantees which
> > wouldn't be incompatible with more conservative scale guarantees to
> > start with.
> 
> Just talking with Neil about this issue and we seemed to instead be
> erring towards another approach which is to just expose a
> cogl_get_time() or cogl_get_clock_time() function which lets
> applications query the time for *now* from the same clock that
> presentation (and potentially, in the future, other) time stamps come
> from. This would also be consistent with how gstreamer exposes clocks
> and provides a means for applications to easily handle their own
> mappings.
> 
> The main issue here is that we want to encapsulate the implementation
> details for the clock source used by Cogl but also enable absolute
> mappings for certain things such a/v synchronization. One approach -
> that you've been pushing for so far - is to promise all timestamps be
> mapped to a well known system clock. Personally I'm still not keen on
> this because potentially that system clock is merely an unnecessary
> middle man and if we are to unconditionally map into that time line we
> also run the risk of no longer being able to guarantee monotonicity
> which ideally i'd like us to be able to offer from Cogl.

Do you see trying to enforce monotonicity on gettimeofday() values - it
sounds like you could end up with a complicated clock implementation
inside of Cogl.

>  This approach
> also requires us to pick a canonical system clock for each platform,
> and although QueryPerformanceCounter would be a natural choice on
> windows, on OSX the mach system time apis are notably more complicated
> to use and it would be harder for us to clearly document that
> canonical system clock.
> 
> Anyway, fingers crossed, we can come to an agreement about this soon.
> My latest preference is for the _get_time() time api.  A notable
> disadvantage to introducing the
> _gst_frame_info_get_presentation_time() api is that it introduces a
> dependency on gstreamer and although that's not a problem per se, it
> is perhaps a bit over kill for this issue.

The get_time() API is workable for me.

- Owen