Re: coordinating idle events and redraws

[Owen Taylor <owt1 cornell edu>]

Marc Ewing <marc@redhat.com> writes:

> > I think what is needed is priorities for the idle handlers.
> > By default, the resize and redraw handlers should have a higher
> > priority than the applications handlers, because from the
> > applications point of view GTK isn't idle until it has 
> > executed them. Going on the TODO list...
> 
> I agree.  Either that or two distinct idle queues, one for
> GTK, and one for the app which only runs when the GTK idle
> queue is empty.
> 
> Perhaps only two priorities are needed, one for internal
> handlers and one for application level handlers?

Keeping a single prioritized idle queue seems better to me.
It is more flexible, about as easy to implement, and I tend
to think of the main loop as providing generic event loop
functionality in a way that is somewhat separate from the
rest of GTK. So I'd rather put in a general facility than
a special case for the drawing/resizing code.

Only two priorities are needed, but it doesn't cost anything
to have allow general integer priorities. I'm planning
to make the default priority 0 and put the redraw/resize
handlers at -10. Scheduling will be simply starvation.
A handler never runs if there are handlers at a higher
priority.

[...]

> I guess what I was getting at was the original problem in a different
> way.  Since GTK and the app were sharing the same idle queue, to
> the *app* its idles handler didn't seem to happen at idle.
> 
> I'd be happy to generate a patch to add priorities to the idle
> handlers, if that what you think is the right thing to do.
> Just let me know.

It's probably easier for me to do it. I'm going to change things
around with gtk_idle_add anyways as part of the _interp() changes,
and I'm already pretty familiar with that part of the code.

Assuming that it goes as easily as I think, I'll do it this
evening.

Regards,
                                        Owen