Re: Input event reduction

[Stefan Salewski <mail ssalewski de>]

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 :-(

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.

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.
Unfortunately that may take a few hundred milliseconds for each full
update.

Currently I wonder if the call of gtk3.mainIteration() inside the idle
function is possible and if it would help updating the display. In my
first draft of the Nim toy chess I used something like this

while gtk3.eventsPending(): discard gtk3.mainIteration()

to avoid display freeze.