[Cogl] [PATCH 3/3] Add CoglFrameTimings

[Robert Bragg]

> 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. 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.

kind regards,
- Robert


>
> kind regards,
> - Robert
>
>>
>> - Owen
>>
>>