Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: Fix wayland frame callback times

[The Rasterman]

On Fri, 16 Dec 2016 08:47:28 -0600 Derek Foreman  said:

> On 15/12/16 07:44 PM, Carsten Haitzler (The Rasterman) wrote:
> > On Thu, 15 Dec 2016 10:21:51 -0600 Derek Foreman 
> > said:
> >
> >> On 14/12/16 06:58 PM, Carsten Haitzler (The Rasterman) wrote:
> >>> On Tue, 13 Dec 2016 11:54:32 -0800 Derek Foreman 
> >>> said:
> >>>
> >>> just a note. i know the original code was wrong and used unix time... unix
> >>> time is gettimeofday and thus can go forward and back (eg ntp changes) and
> >>> also thus its a huge number rather than ecore_time_get(). still it'll wrap
> >>> at about 49.7 days...
> >>
> >> Ahh, I just assumed the original code used an apropriate efl time
> >> function. :/
> >>
> >> I've updated to use ecore_time_get() - I still get a base time at the
> >> first use of a wayland pixmap because I notice ecore_time_get()'s start
> >> time is undefined.
> >>
> >> Thanks!
> >>
> >>> why not just keep a global serial # and ++ it each time? at least it'll
> >>> wrap only after 4 billion or so pixmap frees (that's going to be an
> >>> exceedingly long time i would guess vs using ms)? isn't this just meant
> >>> to be some unique serial number not a timestamp? technically this also
> >>> means multiple pixmap frees in a row there will get the same serial...
> >>
> >> The wayland spec for surface.frame states:
> >> "The callback_data passed in the callback is the current time, in
> >> milliseconds, with an undefined base."
> >>
> >> I'm actually pinging a few people about this since I'm pretty sure
> >> that's not what anyone meant, but it appears to be what we've implemented.
> >>
> >> Surely this should be the time that a frame submitted immediately will
> >> actually hit scanout (this can be checked with an asynchronous vblank
> >> wait ioctl).
> >>
> >> Will try to sort this out today, need to confer with some other wayland
> >> devs and maybe have the spec text clarified.
> >
> > hmm ok. because "current time" since some undefined point i dont see as
> > particularly useful... the time it hits scanout makes sense. but now what it
> > currently is or even after stopping being unix time and being monotonic...
> 
> I'm being told that "current time" is indeed the intent of the spec, and 
> that most clients should just ignore it.  sigh.

WTH is the point of it then? totally weird.

> Weston actually checks the time of the upcoming vblank and sends that, 
> which is decidedly out of spec behaviour, but potentially useful.  I'm 
> not sure whether to follow that or not.

seems more useful at any rate. its a time point that means something...

> There's a presentation timing extension that can be used for better 
> timing, but I haven't looked into it.
> 
> So, the tl;dr?  We're now compliant with the spec.
> 
> But we don't have to like it. :)

hehehe. yeah. but at least not unix_time. :) that only is meant for actually
displaying a clock to a human... :)

> >> Thanks,
> >> Derek
> >>
>  derekf pushed a commit to branch master.
> 
>  http://git.enlightenment.org/core/enlightenment.git/commit/?id=0493abf457331fc604e2aa64eb51448fada09913
> 
>  commit 0493abf457331fc604e2aa64eb51448fada09913
>  Author: Derek Foreman 
>  Date:   Tue Dec 13 13:53:18 2016 -0600
> 
>  Fix wayland frame callback times
> 
>  ecore_time_unix_get() * 1000 is too big to fit in a uint32, so take
>  the time we instantiate the wayland pixmap hash and use that as a base.
>  ---
>   src/bin/e_pixmap.c | 10 --
>   1 file changed, 8 insertions(+), 2 deletions(-)
> 
>  diff --git a/src/bin/e_pixmap.c b/src/bin/e_pixmap.c
>  index f46a994..8e072a0 100644
>  --- a/src/bin/e_pixmap.c
>  +++ b/src/bin/e_pixmap.c
>  @@ -64,6 +64,8 @@ struct _E_Pixmap
> 
>   #ifdef HAVE_WAYLAND
> 
>  +double wayland_time_base;
>  +
>   static void
>   _e_pixmap_cb_deferred_buffer_destroy(struct wl_listener *listener, void
>  *data EINA_UNUSED) {
>  @@ -342,7 +344,10 @@ e_pixmap_new(E_Pixmap_Type type, ...)
>  }
> }
>   else
>  -  pixmaps[type] = eina_hash_int64_new
>  ((Eina_Free_Cb)_e_pixmap_free);
>  +  {
>  + pixmaps[type] = eina_hash_int64_new
>  ((Eina_Free_Cb)_e_pixmap_free);
>  + wayland_time_base = ecore_time_unix_get();
>  +  }
>   cp = _e_pixmap_new(type);
>   cp->win = id;
>   eina_hash_add(pixmaps[type], , cp);
>  @@ -798,7 +803,8 @@ e_pixmap_image_clear(E_Pixmap *cp, Eina_Bool cache)
>    cd->frames = NULL;
>    EINA_LIST_FREE(free_list, cb)
>  {
>  -  wl_callback_send_done(cb, ecore_time_unix_get() *
>  1000);
>  +  double t = ecore_time_unix_get() - 

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: Fix wayland frame callback times

[Derek Foreman]

On 15/12/16 07:44 PM, Carsten Haitzler (The Rasterman) wrote:
> On Thu, 15 Dec 2016 10:21:51 -0600 Derek Foreman  
> said:
>
>> On 14/12/16 06:58 PM, Carsten Haitzler (The Rasterman) wrote:
>>> On Tue, 13 Dec 2016 11:54:32 -0800 Derek Foreman 
>>> said:
>>>
>>> just a note. i know the original code was wrong and used unix time... unix
>>> time is gettimeofday and thus can go forward and back (eg ntp changes) and
>>> also thus its a huge number rather than ecore_time_get(). still it'll wrap
>>> at about 49.7 days...
>>
>> Ahh, I just assumed the original code used an apropriate efl time
>> function. :/
>>
>> I've updated to use ecore_time_get() - I still get a base time at the
>> first use of a wayland pixmap because I notice ecore_time_get()'s start
>> time is undefined.
>>
>> Thanks!
>>
>>> why not just keep a global serial # and ++ it each time? at least it'll wrap
>>> only after 4 billion or so pixmap frees (that's going to be an exceedingly
>>> long time i would guess vs using ms)? isn't this just meant to be some
>>> unique serial number not a timestamp? technically this also means multiple
>>> pixmap frees in a row there will get the same serial...
>>
>> The wayland spec for surface.frame states:
>> "The callback_data passed in the callback is the current time, in
>> milliseconds, with an undefined base."
>>
>> I'm actually pinging a few people about this since I'm pretty sure
>> that's not what anyone meant, but it appears to be what we've implemented.
>>
>> Surely this should be the time that a frame submitted immediately will
>> actually hit scanout (this can be checked with an asynchronous vblank
>> wait ioctl).
>>
>> Will try to sort this out today, need to confer with some other wayland
>> devs and maybe have the spec text clarified.
>
> hmm ok. because "current time" since some undefined point i dont see as
> particularly useful... the time it hits scanout makes sense. but now what it
> currently is or even after stopping being unix time and being monotonic...

I'm being told that "current time" is indeed the intent of the spec, and 
that most clients should just ignore it.  sigh.

Weston actually checks the time of the upcoming vblank and sends that, 
which is decidedly out of spec behaviour, but potentially useful.  I'm 
not sure whether to follow that or not.

There's a presentation timing extension that can be used for better 
timing, but I haven't looked into it.

So, the tl;dr?  We're now compliant with the spec.

But we don't have to like it. :)

>> Thanks,
>> Derek
>>
 derekf pushed a commit to branch master.

 http://git.enlightenment.org/core/enlightenment.git/commit/?id=0493abf457331fc604e2aa64eb51448fada09913

 commit 0493abf457331fc604e2aa64eb51448fada09913
 Author: Derek Foreman 
 Date:   Tue Dec 13 13:53:18 2016 -0600

 Fix wayland frame callback times

 ecore_time_unix_get() * 1000 is too big to fit in a uint32, so take the
 time we instantiate the wayland pixmap hash and use that as a base.
 ---
  src/bin/e_pixmap.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

 diff --git a/src/bin/e_pixmap.c b/src/bin/e_pixmap.c
 index f46a994..8e072a0 100644
 --- a/src/bin/e_pixmap.c
 +++ b/src/bin/e_pixmap.c
 @@ -64,6 +64,8 @@ struct _E_Pixmap

  #ifdef HAVE_WAYLAND

 +double wayland_time_base;
 +
  static void
  _e_pixmap_cb_deferred_buffer_destroy(struct wl_listener *listener, void
 *data EINA_UNUSED) {
 @@ -342,7 +344,10 @@ e_pixmap_new(E_Pixmap_Type type, ...)
 }
}
  else
 -  pixmaps[type] = eina_hash_int64_new
 ((Eina_Free_Cb)_e_pixmap_free);
 +  {
 + pixmaps[type] = eina_hash_int64_new
 ((Eina_Free_Cb)_e_pixmap_free);
 + wayland_time_base = ecore_time_unix_get();
 +  }
  cp = _e_pixmap_new(type);
  cp->win = id;
  eina_hash_add(pixmaps[type], , cp);
 @@ -798,7 +803,8 @@ e_pixmap_image_clear(E_Pixmap *cp, Eina_Bool cache)
   cd->frames = NULL;
   EINA_LIST_FREE(free_list, cb)
 {
 -  wl_callback_send_done(cb, ecore_time_unix_get() * 1000);
 +  double t = ecore_time_unix_get() - wayland_time_base;
 +  wl_callback_send_done(cb, t * 1000);
wl_resource_destroy(cb);
 }
}

 --


>>>
>>>
>>
>
>


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: Fix wayland frame callback times

[The Rasterman]

On Thu, 15 Dec 2016 10:21:51 -0600 Derek Foreman  said:

> On 14/12/16 06:58 PM, Carsten Haitzler (The Rasterman) wrote:
> > On Tue, 13 Dec 2016 11:54:32 -0800 Derek Foreman 
> > said:
> >
> > just a note. i know the original code was wrong and used unix time... unix
> > time is gettimeofday and thus can go forward and back (eg ntp changes) and
> > also thus its a huge number rather than ecore_time_get(). still it'll wrap
> > at about 49.7 days...
> 
> Ahh, I just assumed the original code used an apropriate efl time 
> function. :/
> 
> I've updated to use ecore_time_get() - I still get a base time at the 
> first use of a wayland pixmap because I notice ecore_time_get()'s start 
> time is undefined.
> 
> Thanks!
> 
> > why not just keep a global serial # and ++ it each time? at least it'll wrap
> > only after 4 billion or so pixmap frees (that's going to be an exceedingly
> > long time i would guess vs using ms)? isn't this just meant to be some
> > unique serial number not a timestamp? technically this also means multiple
> > pixmap frees in a row there will get the same serial...
> 
> The wayland spec for surface.frame states:
> "The callback_data passed in the callback is the current time, in 
> milliseconds, with an undefined base."
> 
> I'm actually pinging a few people about this since I'm pretty sure 
> that's not what anyone meant, but it appears to be what we've implemented.
> 
> Surely this should be the time that a frame submitted immediately will 
> actually hit scanout (this can be checked with an asynchronous vblank 
> wait ioctl).
> 
> Will try to sort this out today, need to confer with some other wayland 
> devs and maybe have the spec text clarified.

hmm ok. because "current time" since some undefined point i dont see as
particularly useful... the time it hits scanout makes sense. but now what it
currently is or even after stopping being unix time and being monotonic...

> Thanks,
> Derek
> 
> >> derekf pushed a commit to branch master.
> >>
> >> http://git.enlightenment.org/core/enlightenment.git/commit/?id=0493abf457331fc604e2aa64eb51448fada09913
> >>
> >> commit 0493abf457331fc604e2aa64eb51448fada09913
> >> Author: Derek Foreman 
> >> Date:   Tue Dec 13 13:53:18 2016 -0600
> >>
> >> Fix wayland frame callback times
> >>
> >> ecore_time_unix_get() * 1000 is too big to fit in a uint32, so take the
> >> time we instantiate the wayland pixmap hash and use that as a base.
> >> ---
> >>  src/bin/e_pixmap.c | 10 --
> >>  1 file changed, 8 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/src/bin/e_pixmap.c b/src/bin/e_pixmap.c
> >> index f46a994..8e072a0 100644
> >> --- a/src/bin/e_pixmap.c
> >> +++ b/src/bin/e_pixmap.c
> >> @@ -64,6 +64,8 @@ struct _E_Pixmap
> >>
> >>  #ifdef HAVE_WAYLAND
> >>
> >> +double wayland_time_base;
> >> +
> >>  static void
> >>  _e_pixmap_cb_deferred_buffer_destroy(struct wl_listener *listener, void
> >> *data EINA_UNUSED) {
> >> @@ -342,7 +344,10 @@ e_pixmap_new(E_Pixmap_Type type, ...)
> >> }
> >>}
> >>  else
> >> -  pixmaps[type] = eina_hash_int64_new
> >> ((Eina_Free_Cb)_e_pixmap_free);
> >> +  {
> >> + pixmaps[type] = eina_hash_int64_new
> >> ((Eina_Free_Cb)_e_pixmap_free);
> >> + wayland_time_base = ecore_time_unix_get();
> >> +  }
> >>  cp = _e_pixmap_new(type);
> >>  cp->win = id;
> >>  eina_hash_add(pixmaps[type], , cp);
> >> @@ -798,7 +803,8 @@ e_pixmap_image_clear(E_Pixmap *cp, Eina_Bool cache)
> >>   cd->frames = NULL;
> >>   EINA_LIST_FREE(free_list, cb)
> >> {
> >> -  wl_callback_send_done(cb, ecore_time_unix_get() * 1000);
> >> +  double t = ecore_time_unix_get() - wayland_time_base;
> >> +  wl_callback_send_done(cb, t * 1000);
> >>wl_resource_destroy(cb);
> >> }
> >>}
> >>
> >> --
> >>
> >>
> >
> >
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: Fix wayland frame callback times

[Derek Foreman]

On 14/12/16 06:58 PM, Carsten Haitzler (The Rasterman) wrote:
> On Tue, 13 Dec 2016 11:54:32 -0800 Derek Foreman  
> said:
>
> just a note. i know the original code was wrong and used unix time... unix 
> time
> is gettimeofday and thus can go forward and back (eg ntp changes) and also 
> thus
> its a huge number rather than ecore_time_get(). still it'll wrap at about 49.7
> days...

Ahh, I just assumed the original code used an apropriate efl time 
function. :/

I've updated to use ecore_time_get() - I still get a base time at the 
first use of a wayland pixmap because I notice ecore_time_get()'s start 
time is undefined.

Thanks!

> why not just keep a global serial # and ++ it each time? at least it'll wrap
> only after 4 billion or so pixmap frees (that's going to be an exceedingly 
> long
> time i would guess vs using ms)? isn't this just meant to be some unique 
> serial
> number not a timestamp? technically this also means multiple pixmap frees in a
> row there will get the same serial...

The wayland spec for surface.frame states:
"The callback_data passed in the callback is the current time, in 
milliseconds, with an undefined base."

I'm actually pinging a few people about this since I'm pretty sure 
that's not what anyone meant, but it appears to be what we've implemented.

Surely this should be the time that a frame submitted immediately will 
actually hit scanout (this can be checked with an asynchronous vblank 
wait ioctl).

Will try to sort this out today, need to confer with some other wayland 
devs and maybe have the spec text clarified.

Thanks,
Derek

>> derekf pushed a commit to branch master.
>>
>> http://git.enlightenment.org/core/enlightenment.git/commit/?id=0493abf457331fc604e2aa64eb51448fada09913
>>
>> commit 0493abf457331fc604e2aa64eb51448fada09913
>> Author: Derek Foreman 
>> Date:   Tue Dec 13 13:53:18 2016 -0600
>>
>> Fix wayland frame callback times
>>
>> ecore_time_unix_get() * 1000 is too big to fit in a uint32, so take the
>> time we instantiate the wayland pixmap hash and use that as a base.
>> ---
>>  src/bin/e_pixmap.c | 10 --
>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/bin/e_pixmap.c b/src/bin/e_pixmap.c
>> index f46a994..8e072a0 100644
>> --- a/src/bin/e_pixmap.c
>> +++ b/src/bin/e_pixmap.c
>> @@ -64,6 +64,8 @@ struct _E_Pixmap
>>
>>  #ifdef HAVE_WAYLAND
>>
>> +double wayland_time_base;
>> +
>>  static void
>>  _e_pixmap_cb_deferred_buffer_destroy(struct wl_listener *listener, void
>> *data EINA_UNUSED) {
>> @@ -342,7 +344,10 @@ e_pixmap_new(E_Pixmap_Type type, ...)
>> }
>>}
>>  else
>> -  pixmaps[type] = eina_hash_int64_new((Eina_Free_Cb)_e_pixmap_free);
>> +  {
>> + pixmaps[type] = eina_hash_int64_new
>> ((Eina_Free_Cb)_e_pixmap_free);
>> + wayland_time_base = ecore_time_unix_get();
>> +  }
>>  cp = _e_pixmap_new(type);
>>  cp->win = id;
>>  eina_hash_add(pixmaps[type], , cp);
>> @@ -798,7 +803,8 @@ e_pixmap_image_clear(E_Pixmap *cp, Eina_Bool cache)
>>   cd->frames = NULL;
>>   EINA_LIST_FREE(free_list, cb)
>> {
>> -  wl_callback_send_done(cb, ecore_time_unix_get() * 1000);
>> +  double t = ecore_time_unix_get() - wayland_time_base;
>> +  wl_callback_send_done(cb, t * 1000);
>>wl_resource_destroy(cb);
>> }
>>}
>>
>> --
>>
>>
>
>


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: Fix wayland frame callback times

[The Rasterman]

On Thu, 15 Dec 2016 09:58:04 +0900 Carsten Haitzler (The Rasterman)
 said:

> On Tue, 13 Dec 2016 11:54:32 -0800 Derek Foreman 
> said:
> 
> just a note. i know the original code was wrong and used unix time... unix
> time is gettimeofday and thus can go forward and back (eg ntp changes) and
> also thus its a huge number rather than ecore_time_get(). still it'll wrap at
> about 49.7 days...
> 
> why not just keep a global serial # and ++ it each time? at least it'll wrap
> only after 4 billion or so pixmap frees (that's going to be an exceedingly
> long time i would guess vs using ms)? isn't this just meant to be some unique
> serial number not a timestamp? technically this also means multiple pixmap
> frees in a row there will get the same serial...

and fyi i have a local pending commit (among others) for this too..

> > derekf pushed a commit to branch master.
> > 
> > http://git.enlightenment.org/core/enlightenment.git/commit/?id=0493abf457331fc604e2aa64eb51448fada09913
> > 
> > commit 0493abf457331fc604e2aa64eb51448fada09913
> > Author: Derek Foreman 
> > Date:   Tue Dec 13 13:53:18 2016 -0600
> > 
> > Fix wayland frame callback times
> > 
> > ecore_time_unix_get() * 1000 is too big to fit in a uint32, so take the
> > time we instantiate the wayland pixmap hash and use that as a base.
> > ---
> >  src/bin/e_pixmap.c | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/bin/e_pixmap.c b/src/bin/e_pixmap.c
> > index f46a994..8e072a0 100644
> > --- a/src/bin/e_pixmap.c
> > +++ b/src/bin/e_pixmap.c
> > @@ -64,6 +64,8 @@ struct _E_Pixmap
> >  
> >  #ifdef HAVE_WAYLAND
> >  
> > +double wayland_time_base;
> > +
> >  static void
> >  _e_pixmap_cb_deferred_buffer_destroy(struct wl_listener *listener, void
> > *data EINA_UNUSED) {
> > @@ -342,7 +344,10 @@ e_pixmap_new(E_Pixmap_Type type, ...)
> > }
> >}
> >  else
> > -  pixmaps[type] = eina_hash_int64_new
> > ((Eina_Free_Cb)_e_pixmap_free);
> > +  {
> > + pixmaps[type] = eina_hash_int64_new
> > ((Eina_Free_Cb)_e_pixmap_free);
> > + wayland_time_base = ecore_time_unix_get();
> > +  }
> >  cp = _e_pixmap_new(type);
> >  cp->win = id;
> >  eina_hash_add(pixmaps[type], , cp);
> > @@ -798,7 +803,8 @@ e_pixmap_image_clear(E_Pixmap *cp, Eina_Bool cache)
> >   cd->frames = NULL;
> >   EINA_LIST_FREE(free_list, cb)
> > {
> > -  wl_callback_send_done(cb, ecore_time_unix_get() * 1000);
> > +  double t = ecore_time_unix_get() - wayland_time_base;
> > +  wl_callback_send_done(cb, t * 1000);
> >wl_resource_destroy(cb);
> > }
> >}
> > 
> > -- 
> > 
> > 
> 
> 
> -- 
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
> 
> 
> --
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: Fix wayland frame callback times

[The Rasterman]

On Tue, 13 Dec 2016 11:54:32 -0800 Derek Foreman  said:

just a note. i know the original code was wrong and used unix time... unix time
is gettimeofday and thus can go forward and back (eg ntp changes) and also thus
its a huge number rather than ecore_time_get(). still it'll wrap at about 49.7
days...

why not just keep a global serial # and ++ it each time? at least it'll wrap
only after 4 billion or so pixmap frees (that's going to be an exceedingly long
time i would guess vs using ms)? isn't this just meant to be some unique serial
number not a timestamp? technically this also means multiple pixmap frees in a
row there will get the same serial...

> derekf pushed a commit to branch master.
> 
> http://git.enlightenment.org/core/enlightenment.git/commit/?id=0493abf457331fc604e2aa64eb51448fada09913
> 
> commit 0493abf457331fc604e2aa64eb51448fada09913
> Author: Derek Foreman 
> Date:   Tue Dec 13 13:53:18 2016 -0600
> 
> Fix wayland frame callback times
> 
> ecore_time_unix_get() * 1000 is too big to fit in a uint32, so take the
> time we instantiate the wayland pixmap hash and use that as a base.
> ---
>  src/bin/e_pixmap.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/src/bin/e_pixmap.c b/src/bin/e_pixmap.c
> index f46a994..8e072a0 100644
> --- a/src/bin/e_pixmap.c
> +++ b/src/bin/e_pixmap.c
> @@ -64,6 +64,8 @@ struct _E_Pixmap
>  
>  #ifdef HAVE_WAYLAND
>  
> +double wayland_time_base;
> +
>  static void
>  _e_pixmap_cb_deferred_buffer_destroy(struct wl_listener *listener, void
> *data EINA_UNUSED) {
> @@ -342,7 +344,10 @@ e_pixmap_new(E_Pixmap_Type type, ...)
> }
>}
>  else
> -  pixmaps[type] = eina_hash_int64_new((Eina_Free_Cb)_e_pixmap_free);
> +  {
> + pixmaps[type] = eina_hash_int64_new
> ((Eina_Free_Cb)_e_pixmap_free);
> + wayland_time_base = ecore_time_unix_get();
> +  }
>  cp = _e_pixmap_new(type);
>  cp->win = id;
>  eina_hash_add(pixmaps[type], , cp);
> @@ -798,7 +803,8 @@ e_pixmap_image_clear(E_Pixmap *cp, Eina_Bool cache)
>   cd->frames = NULL;
>   EINA_LIST_FREE(free_list, cb)
> {
> -  wl_callback_send_done(cb, ecore_time_unix_get() * 1000);
> +  double t = ecore_time_unix_get() - wayland_time_base;
> +  wl_callback_send_done(cb, t * 1000);
>wl_resource_destroy(cb);
> }
>}
> 
> -- 
> 
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel