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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
