On Sun, Oct 29, 2023, 15:10 Elias Naur <mail@eliasnaur.com> wrote:
>
> On Sat, 28 Oct 2023 at 05:23, <fgergo@gmail.com> wrote:
> >
> > On 10/27/23, Elias Naur <mail@eliasnaur.com> wrote:
> > > On Fri, 27 Oct 2023 at 11:40, Chris Waldon
> > > <christopher.waldon.dev@gmail.com> wrote:
> > >>
> > >> On Wed, Oct 25, 2023 at 5:35 AM <fgergo@gmail.com> wrote:
> > >> >
> > >> > Is there a specific design reason why the 2 events' timestamps are
> > >> > stored as different types?
> > >>
> > >> I honestly don't know. Elias?
> > >>
> > >
> > > The idea is that we can't guarantee an absolute timestamp for events.
> > Thanks!
> >
> > > Representing event time as a time.Duration allows us to leave the time reference
> > > undefined.
> > >
> > > FrameEvent.Now is just (1) a time.Now cache and (2) a way to eliminate time
> > > skew across a frame.
> > Do you mean a "... way for gio based programs to eleminate time skew
> > while building a frame."
>
> Yes.

Thanks!

> > Iiuc gio does not need to propagate this cached value to function properly?
> >
>
> In a sense, yes, it's for the service of Gio programs to eliminate the (rare)
> animation skew that may happen if components query time.Now independently.

Thanks!
>
>
> > Iiu FrameEvent.Now could have been a (calculated) time.Duration type
> > as well. Please note: I don't want to change anything, I'd just like
> > to understand, because I plan to use timing details.
> >
>
> FrameEvent.Now could be a time.Duration. However, I worry that it would then be expected to be compatible with pointer.Event.Time.

Not compatible as not be comparable?