GPeriodic update



hi,

After a lot of travel I've been at home for more than 24 hours.  I got a
chance to read through the GPeriodic thread (mostly between Owen and
Havoc).

I've done the following as a first attempt to improve the situation:

GPeriodic now has two GSource priority levels, which it calls "high" and
"low".  The high level is the normal priority level at which the
GPeriodic source is registered.  There is not normally a source
registered at the low level.

GPeriodic measures how long its "run" function takes (the sum of
dispatching tick and repair functions).  It then multiples this amount
by two.  If the result is bigger than the duration of a single frame
then it sets an internal flag to indicate that it wants to skip frames.

The number of frames skipped is the (rounded down) whole number of
frames corresponding to twice the time it took to do the painting.  This
means that if you took less than half of the frame time to do painting
then no frames will be skipped.  More than half (but not one whole frame
time) then 1 frame will be skipped, and so on.

That means that at least 50% of the time is given to "other things".

The source continues to be registered with the mainloop at its high
priority -- it just signals that it doesn't want to run until the next
frame time (as delayed by the skip count).

At any time that the skip count is set to a non-zero value, an idle is
added to the mainloop at the "low" priority level.  If this idle gets a
chance to run then it directly sets the skip count to zero.  This way we
can use up to 100% of the CPU for painting, as long as nothing else is
trying to run.

I believe that this approach is the essence of what we should do and I
think that it's the most direct way to do it.  The details about
deciding exactly how many frames to skip (eg: based on a rolling average
instead of one immediate measurement) should still be worked out, of
course.

Patch is here:

http://git.gnome.org/browse/glib/commit/?id=63b87b2c26bf983823f83943b8d752bd053ce539

I'm aware of the increasing ickiness of my "reset our stride" code and
I'm already considering the best way to deal with this.

Comments are extremely welcome at this point.

Otherwise, see you in Boston. :)

Cheers



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]