Re: How to maintain responsiveness during long functions?

[James Henstridge <james daa com au>]

When I was coding the rpmfind stuff in gnorpm, I used the
gtk_main_iteration() thing quite a bit, and it did slow down what I was
doing a bit.

Generally it is not too difficult to split an algorithm into parts that
can be run as idle functions.  If there is a main loop in the algorithm
which takes up most of the time, you just put the body of the loop into
the idle function, and change all the state variables to members of some
structure (if you have derived a new GtkWidget, this is usually the best
place to keep the state).

When adding the idle function, save the return value somewhere easily
accessible.

At the end of the idle funciton, all it has to do is increment the counter
(or move along a list, or whatever).  If another loop is required, return
TRUE.  If not, clean up all the state variables, set the variable holding
the idle tag to zero, and return FALSE.

You can tell when the idle function is running because the tag variable is
non zero.  The idle can then be killed with gtk_idle_remove, followed by
cleaning up the state variables.

As you can see, it is possible to play around with splitting up the
algorithm without having to know too much about how it works.  It would
probably be a good idea to try this out, so you can compare speed and
responsiveness.

James.

--
Email: james@daa.com.au
WWW:   http://www.daa.com.au/~james/


On Thu, 24 Jun 1999, Ian Peters wrote:

> On Fri, Jun 25, 1999 at 07:40:52AM +0800, James Henstridge wrote:
> > The ideal solution is to split up the working into small chunks and get an
> > idle function to take care of it.
> 
> This is what I thought; unfortunately, this has the drawback of
> requiring me to actually /understand/ the code that people have gifted
> to me ... :-)
> 
> > The other solution is to call the following code during the working every
> > now and again:
> >   if (gtk_events_pending())
> >     gtk_main_iteration();
> 
> This is what I initially tried, from stumbling through header files
> looking for answers.
> 
> > In general, I have found that the first solution runs faster and gives a
> > more responsive interface, but requires a bit more thinking to implement
> > correctly.  (It also has the advantage that it is easier to cancel the
> > thinking, if that is important).
> 
> Yes, the second solution is not optimal from a responsiveness point of
> view, and does slow down the algorithm somewhat.  Also, quitting the
> program doesn't work, which follows when I tracked down how
> gtk_main_quit() actually goes about quitting.  I wonder if there's any
> way around this, though ...
> 
> Thanks for the help, and if you've got any thoughts on how to safely
> make Exit work with the easy option, I'd be very grateful again.
> 
> I should learn never to expect an easy answer ... :-)
> 
> -- 
> Ian Peters  | GnuPG Key ID 5C23D20C    | "He that breaks a thing to find out
> itp@gnu.org | E584 2558 FAC3 BEAB EFAC |  what it is has left the path of
> itp@acm.org | FC74 CFED 7E24 5C23 D20C |  wisdom." -- J.R.R. Tolkien
>