GNU bug report logs - #61667
29.0.60; Failure to redisplay

Previous Next

Full log

Message #248 received at 61667 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: luangruo <at> yahoo.com, 61667 <at> debbugs.gnu.org, gregory <at> heytings.org
Subject: Re: bug#61667: 29.0.60; Failure to redisplay
Date: Sat, 25 Feb 2023 09:12:14 +0200

> Date: Fri, 24 Feb 2023 23:49:05 +0200
> Cc: luangruo <at> yahoo.com, 61667 <at> debbugs.gnu.org, gregory <at> heytings.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> On 24/02/2023 23:19, Eli Zaretskii wrote:
> >> Date: Fri, 24 Feb 2023 23:03:12 +0200
> >> Cc:luangruo <at> yahoo.com,61667 <at> debbugs.gnu.org,gregory <at> heytings.org
> >> From: Dmitry Gutov<dgutov <at> yandex.ru>
> >>
> >> +int64_t now_millis() {
> >> +  struct timespec now;
> >> +  timespec_get(&now, TIME_UTC);
> >> +
> >> +  return ((int64_t) now.tv_sec) * 1000 + ((int64_t) now.tv_nsec) / 1000;
> >                                                                        ^^^^
> > That 1000 should be 1000000, right?
> 
> Right, sorry. I misread it in the doc for "microseconds".
> 
> The result makes no difference, though: now only zeros are printed (and 
> sometimes 1):
> 
> [x_set_name] time to x_set_name_internal: 0
> [x_set_name] time to x_set_name_internal: 0

Well, 1 msec is a far cry from 20 or 50...

> So the calls take < 1ms.

Yes.  Which means these X and GTK calls are not the direct culprit of
the delay.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.