Re: Input event reduction

[Nicola Fontana <ntd entidi it>]

Il Thu, 30 Mar 2017 09:38:41 +0200 Stefan Salewski <mail ssalewski de> scrisse:

> On Wed, 2017-03-29 at 23:26 +0200, Nicola Fontana wrote:
> >  
> >
> > idle functions do *not* run in the background so if you don't
> > release the CPU you will experience what you described.
> >
> > AFAIK all the GMainLoop code is single-threaded hence, as a
> > consequence, you will block the UI whenever the CPU is busy
> > running your code, being it inside a signal handler, a timeout
> > function or (as in your case) an idle function.
> >
> > Just avoid loops when you know they are expensive. Instead
> > leverage the cyclic nature of GMainLoop for iterating over your
> > code, i.e. by respawning your idle function as much as needed.
> >   
>
> In that case it is really a bad idea to have a outer loop in that idle
> function :-(

As said you can leverage the main loop and unroll yours, e.g.:

gboolean my_idle_callback()
{
    gint n;
    for (n = 0; n < 100; ++n) {
        ...
    }
    return FALSE;
}

should become:

gboolean my_unrolled_idle_callback()
{
    static gint n = 0;
    ...
    ++n;
    return n < 100;
}

Depending on your use case, the above could or could not be
possible.

> So I have to go back to my initial idea -- create a thread which gets a
> message for each "changed" signal, and then calls an idle function only
> for the last message in the queue each. I have to use
> gdk_threads_add_idle() then.

This is probably the cleanest solution, although I don't
understand why you would have to use gdk_threads_add_idle().

> The task of that idle function in my current use case would be to get
> highlight syntax information from the IDE process called nimsuggest and
> then to apply the corresponding tags to gtksource textbuffer.

IMO it is essential to split your code in two parts: (1) gathering
the highlight information and (2) applying it to the textbuffer.

(1) can be run entirely in the working thread (hence non-blocking)
while (2) must be implemented as a callback to be run in the GTK+
thread. I cannot believe (2) takes tenths of second.

When you are ready from (1) you can spawn the idle callback with
g_source_attach()... no needs for gdk_threads_add_idle(). In the
following StackOverflow answer I provided an example in C:

http://stackoverflow.com/questions/27950493/safety-of-using-pthreads-in-gtk2-0-application#27990662

Ciao.
-- 
Nicola