Re: Input event reduction
- From: Stefan Salewski <mail ssalewski de>
- To: Nicola Fontana <ntd entidi it>
- Cc: "gtk-app-devel-list gnome org" <gtk-app-devel-list gnome org>
- Subject: Re: Input event reduction
- Date: Thu, 30 Mar 2017 11:35:36 +0200
On Thu, 2017-03-30 at 11:10 +0200, Nicola Fontana wrote:
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.
Ah yes, that is an interesting idea.
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().
I think gdk_threads_add_idle() is the recommended way to update the GTK
GUI from inside a second thread. I am doing it in the current version
of the editor already for querying and displaying extended symbol
information, see https://github.com/ngtk3/NEd
Here is where gdk_threads_add_idle() was suggested:
https://developer.gnome.org/gdk3/stable/gdk3-Threads.html
"You can schedule work in the main thread safely from other threads by
using gdk_threads_add_idle() and gdk_threads_add_timeout()"
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.
Yes, that was my thoughts too. It would imply some additional code, but
may be the best solution.
(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
Thanks for that suggestion, I will look at the stackoverflow example.
And indeed, applying the text tags to the gtksource buffer is finally
the only critical part. I dont know how fast that really is, I would
assume that it takes less than 50 ms, what would be fine. If it really
is slow, I may split it in multiple parts/calls.
[
Date Prev][
Date Next] [
Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]