Re: About gtk_timeout_add

[Owen Taylor <otaylor redhat com>]

"Paul" <jarlongl ms21 hinet net> writes:

> > so resolution is limited to what the os provides (i.e.: linux 10ms).
>
> i use setitimer to verify the resolution, it is 10ms for linux. That is if
> the period >= 10(ms), the alarm signal handler is called (1000/period)
> times/second. if period <= 10(ms), the handler is called 100 times/second. i
> guess it will be the same for gtk_timeut_add, but it is different. But i do
> not know why? i know the call rate will depend on complexity of the callback
> function, so in order to test the called rate, the only job in callback
> function is to increase the counter.

Try the following program - it is more like what GTK+ is doing:

== timeit.c ====
#include <stddef.h>
#include <sys/poll.h>

int main()
{
  int i;

  for (i=0; i<100; i++)
    poll(NULL,0,1);
  
  return 0;
}
=================

$ time timeit.c

real 0m2.012s
user 0m0.000s
sys  0m0.000s

That program takes just about 2 seconds to run on my machine. You'd
have to look at the kernel sources to see why this is twice the
"resolution" you got with setitimer, but setitimer isn't very useful
for the kind of things GTK+ is doing - it has to wait for events
coming in from the X server, and so forth, as well as for the 
current timeout.

The corresponding GTK+ program:

==========
#include <gtk/gtk.h>

int count = 100;

gboolean
timeout (gpointer data)
{
  count--;
  if (count == 0)
    {
      gtk_main_quit ();
      return FALSE;
    }
  else
    return TRUE;
}

int main (int argc, char **argv)
{
  gtk_init (&argc, &argv);

  g_timeout_add (10, timeout, NULL);

  gtk_main ();

  return 0;
}
==========

Also takes just about exactly 2 seconds to run. (The few
milliseconds of overhead you may notice is all the gtk_init()
call.)

Regards,
                                        Owen