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 To: Jacques Garrigue Subject: Re: [Lablgtk] CPU consumption with GtkThread Message-ID: <20101215085326.53108569 at alcazar> In-Reply-To: References: <20101214083626.59faf109 at alcazar> <20101214084959.0c5ce2ef at alcazar> <20101215074302.51916f2e@alcazar> 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 wrote: > On Wed, Dec 15, 2010 at 3:43 PM, Maxence Guesdon > wrote: > > On Tue, 14 Dec 2010 12:18:00 +0100 > > Adrien 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