Re: Doubts about GPeriodic

[Havoc Pennington <hp pobox com>]

Hi,

I guess a frame-complete signal (or timer) acts like the 5ms to create
a window for other event sources to run? So painting should not starve
other stuff, the mainloop could dispatch other stuff while the frame
is being completed. Given a gap waiting for frame-completed you don't
need a hardcoded 5ms (makes sense to me).

Re: frame-complete, it of course assumes working drivers... If you
don't have the async frame completed signal you may be back to the 5ms
thing, no? I guess with direct rendering you are just hosed in that
case... with indirect you can use XCB to avoid blocking and then just
dispatch for 5ms, which is what we do, but with direct rendering you
might just have to block. Unless you're using fglrx which vsyncs but
does not block to do so (at least with indirect, not totally sure on
direct). Sigh. The driver workarounds rapidly proliferate. Maybe
clutter team already debugged them all and the workarounds are in
COGL. :-P
I guess COGL or whatever could in theory just send frame-completed
after a fixed 5ms as a workaround on platforms that need it. There's
also ARM and whatever platforms with no X to consider.

Re: priorities, I would think once the frame-complete comes back (or
5ms expires, absent frame-complete) it's appropriate to drop
everything else (unless it's explicitly asked to be super high
priority) and paint. "paint" includes processing entire event queue
and relayout, so that should have the UI sufficiently updated.

You were talking about handling incoming IPC at higher priority than
repaint... it sort of depends on what the IPC is about. For example,
we have some that is UI-related, similar to events, and other that is
basically IO. If you have a flood of IO coming in (say downloading a
big file) then I don't think it's acceptable to wait for that queue to
drain before painting - it could be minutes, not seconds. If you think
about something like the dbus main loop source, the dbus library
doesn't know what the heck is going to be coming in, and you can't
tune the main loop source depending on what kind of message it is.

Anything with a queue doesn't really have a bounded time within which
its GSource won't be ready anymore. Threads only help if you can
squish the queue in the thread... otherwise the unboundedness ends up
in the main thread anyway. For example if you're reading a file, then
if you can parse it and convert it to a small object in the thread,
there's no potential paint starvation problem, but if you need to feed
the whole unbounded dataset over into a TextView/TreeView, then there
is (as you mention).

I feel like most stuff should be below paint priority, not above, and
then each frame should have a window (either "while waiting for
frame-completed" or "fixed time like 5ms" or whatever) in which things
below paint priority are going to run. That way things more or less
can't break, as long as each individual dispatch() is reasonably
fast/bounded.

If most stuff is below paint priority (in order to ensure we keep up
the frame rate), that could be implemented either by making most stuff
an idle, or by making paint priority above default.

"Most stuff should be an idle" is weird to me - seems to make default
priority kind of meaningless and render g_*_add() etc. APIs useless.
Why not make paint priority greater than the default priority, and so
most things should be default, and idle is reserved for things that
it's acceptable to starve?

Conceptually, events+paint _should_ be highest priority - without
those we are hiccuping and breaking interactivity - the only thing is,
they can't run continuously, each frame needs a slice of doing "other
stuff" and that could be a fixed interval, or given decent drivers,
the time during which the GPU is chewing on the frame / waiting on
vsync.

Havoc