Delivered-To: garrigue at math.nagoya-u.ac.jp
Delivered-To: lablgtk at yquem.inria.fr
Date: Wed, 15 Dec 2010 08:53:26 +0100
From: Maxence Guesdon <Maxence.Guesdon at inria.fr>
To: Jacques Garrigue <garrigue at math.nagoya-u.ac.jp>
Subject: Re: [Lablgtk] CPU consumption with GtkThread
Message-ID: <20101215085326.53108569 at alcazar>
In-Reply-To: <AANLkTim8KA0dG_dV5-DxrSwf8anKpFJzTPW4UA0U6K2f at mail.gmail.com>
References: <20101214083626.59faf109 at alcazar> <20101214084959.0c5ce2ef at alcazar>
	<AANLkTi=1e1ve590e+6adrANNtbY0t9hSyz-YvELtAZQN@mail.gmail.com>
	<20101215074302.51916f2e@alcazar>
	<AANLkTim8KA0dG_dV5-DxrSwf8anKpFJzTPW4UA0U6K2f@mail.gmail.com>
Organization: INRIA
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: lablgtk at yquem.inria.fr
Status: U

On Wed, 15 Dec 2010 16:24:17 +0900
Jacques Garrigue <garrigue@math.nagoya-u.ac.jp> wrote:

> On Wed, Dec 15, 2010 at 3:43 PM, Maxence Guesdon
> <Maxence.Guesdon@inria.fr> wrote:
> > On Tue, 14 Dec 2010 12:18:00 +0100
> > Adrien <camaradetux@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> I actually made it adaptive later on[1]. The drawback was that
> >> animations could take more time to update. The adaptative version
> >> worked quite well but reducing the delay wasn't instantaneous. It was
> >> pretty dumb and experimental, I could probably put more thought in it
> >> if needed.
> >> One of my test was using the acid3 test[2]. Basically, each step of
> >> the animation required one iteration of the loop. So depending on your
> >> uses it might or might not be a good idea.
> >
> > Maybe the GtkThread module could allow setting some kind of callback so
> > that the application could change this delay when needed ?
> 
> I was not aware of this GtkThread problem, but I'm certainly not opposed to
> making the delay tweakable by the application. One difficulty is that I suppose
> this depends quite a lot on the OS scheduler, and in particular on its
> granularity,
> so that the application may not know enough to set this value properly, but at
> least it is better than nothing.

I just commited a proposition. 

This allows setting directly the delay with 
  GtkThread.set_do_jobs_delay

The default delay is not 0.013 instead of 0.0001.

There is also a callback which can be passed to GtkThread.main and
GtkThread.thread_main, which is then passed to GtkThread.thread_main_real.

This callback is called at the end of the external loop in
thread_main_real, so that the application can use this callback to set an
adaptative delay policy, as Adrien does in [1].

This callback is not passed to the thread_main function registered in
GMain.main, I don't know if it would be wishable.

I tested the set_do_jobs_delay, not the callback. And my application does
not use threads extensively.


Regards,

Maxence

[1] http://git.ocamlcore.org/cgi-bin/gitweb.cgi?p=caravel/caravel.git;a=blob_plain;f=gtk_thread_bis/gtkThreadBis.ml;hb=67e29bc6550603fa42857569eb6f878f180949f2


_______________________________________________
Lablgtk mailing list
Lablgtk@yquem.inria.fr
http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk