Re: Wait cursor animation does not work properly

[Chris Vine <vine35792468 gmail com>]

On Mon, 04 Sep 2017 09:17:10 +0200
Stefan Salewski <mail ssalewski de> wrote:
> On Sun, 2017-09-03 at 16:54 +0100, Emmanuele Bassi wrote:
> > You're blocking the toolkit's main loop, here. If your application
> > does this, it's broken and needs to be fixed - regardless of what
> > the cursor looks like.
> >
> > The cursor is rendered by the Wayland compositor, but the animation
> > is
> > performed by the toolkit, i.e. it's the toolkit that uploads the
> > cursor's data to the compositor.  
>
> Of course you are right that using g_idle_add() is still blocking the
> GUI. But I think that having an animated Busy cursor makes only sense
> at all when it is animated while a program is doing some heavy
> calculation. So the animated cursor is indeed an indication for a
> short blocked period. My chess engine takes only a few seconds to
> calculate the next move, so creating an own thread is some overkill.
> What I need: User has done his move, so update display, indicate that
> computer is "thinking" for a few seconds, and then update display
> again. I think that should be possible with g_idle_add(). Instead of
> the busy pointer I may set a message to the window title.
>
> Later I may consider indeed using a separate thread -- I did that
> already one year ago for my Ned Nim editor for communicating with the
> nimsuggest process, but I can not remember details currently. Doing it
> really properly may be not easy for a chess engine, as the human
> player should be able to interrupt the computer thinking at arbitrary
> times. Unfortunately there exist very few examples, and some are more
> Python related like

I think you are partly thinking out loud, because you began with "of
course you are right that using g_idle_add() is still blocking the
GUI", but in so far as you were wanting an answer the point is that any
GTK+ program runs a glib event loop in its main (starting) thread.  That
event loop must not be blocked by your "some heavy calculation", whether
in an idle callback or in some GTK+ signal callback or in whatever
other way you may be thinking of doing it in that thread.

The conventional way of dealing with this is for the blocking "heavy
calculation" to be run in a separate worker thread or in a thread pool,
and for that worker thread to post its result back to GTK+ using
g_idle_add().  g_idle_add() is thread safe.  You might also want to look
at GTask (and g_task_run_in_thread()), which follows this approach but
with some additional syntactic sugar.

As to your test case, that works fine in GTK+-3.22 with the X11
backend and the Adwaita theme.  I do not have wayland installed.
Possibly you have found a bug in the wayland backend, depending on
whether anyone else can reproduce your issue.

Chris