Merge lp:~vanvugt/compiz-core/fix-773861-trunk into lp:compiz-core/0.9.5

[Daniel van Vugt]

Fix rendering lagging too far behind what the mouse is doing, such as when dragging windows around. (LP: #773861)

This fix REQUIRES the timer fairness fix from LP: #897045, which is already committed to lp:compiz-core.

[Daniel van Vugt (vanvugt)]

Although this fix makes the lag significantly better than it was, and at least better than it's ever been in compiz, it still doesn't seem good enough to me. Compared to gnome-shell, the lag in compiz is still too much.

[Daniel van Vugt (vanvugt)]

... therefore work in progress again.

[Daniel van Vugt (vanvugt)]

Ready for review again. I can't see how to improve on this fix right now. It may lag slightly more than gnome-shell does, but it's still far better than the existing compiz code.

[Sam Spilsbury (smspillaz)]

What do you think about raising the priority of the event source and having a separate event source for the paint clocks, so that you always have events dispatched in the following order:

Events -> Timers -> Paint Clock.

Although I'm kind of thinking that in this case it should really go

Timers -> Events -> Paint Clock because some plugins set zero-timeout time timers to be dispatched ideally before we return to the event loop.

[Daniel van Vugt (vanvugt)]

Certainly priorities should be what you use for guaranteeing some kind of order. That's how glib is designed.

Raising the event source priority was my first idea. But I discarded the idea because that then put CompEventSource higher priority than all the g_timeout_add sources in Unity (and potentially other glib sources), which created too much risk of starving Unity. So it's too risky to make anything higher priority than default (<G_PRIORITY_DEFAULT).

Painting should always be low priority. In fact, GDK uses:
gdk/gdkevents.h:#define GDK_PRIORITY_REDRAW (G_PRIORITY_HIGH_IDLE + 20)

However, it only became possible to use the lower priorities in compiz after CompTimeoutSource::callback was fixed for bug 897045.

[Daniel van Vugt (vanvugt)]

And yes, I agree painting should have lower priority the timers by default. This could all be solved by my earlier suggestion of using g_timeout_add to implement CompTimer, so that you can control "order" using individual priorities.

[Daniel van Vugt (vanvugt)]

Work in progress again. I'm not confident this change should be proposed until more people give feedback. I'm afraid some people's graphics configs might see worse performance if event bursts are allowed to starve the painting timer like this... Though I haven't seen any proof yet.

[Daniel van Vugt (vanvugt)]

Also, the fix for bug 897045 seems to provide 85% of the improvement. This proposal only adds about another 10% in my view.

[Daniel van Vugt (vanvugt)]

Rejecting this proposal myself. Several better solutions to bug 764330 are under review.

Unmerged revisions

2896. By Daniel van Vugt on 2011-12-12

Fix rendering lagging too far behind what the mouse is doing, such as when
dragging windows around. (LP: #773861)
This fix REQUIRES the timer fairness fix from LP: #897045.

=== modified file 'src/timer.cpp'
--- src/timer.cpp	2011-12-05 06:42:56 +0000
+++ src/timer.cpp	2011-12-12 09:07:27 +0000
@@ -36,24 +36,13 @@
     Glib::Source ()
 {
     /*
-     * Compiz MUST use priority G_PRIORITY_DEFAULT because that's the same
-     * as GDK_PRIORITY_EVENTS.
-     *
-     * Any higher priority than that and you will starve the glib event loop
-     * of X events. That causes stuttering and even complete starvation
-     * can cause compiz to hang inside X11/GLX functions indefinitely.
-     * In the best case, GLX functions would be slowed down by their messages
-     * being prioritized lower than us.
-     *
-     * Any lower priority than that and screen redraws can lag behind
-     * important things like dragging windows around.
-     *
-     * We have an "unfair" scheduling algorithm in the glib main event loop
-     * to thank for all this. Ideally, compiz should be threaded so it never
-     * slows down the handling of X11/GLX messages in the glib main loop, or
-     * vice-versa.
+     * Timers must have below default priority (>G_PRIORITY_DEFAULT).
+     * This is required to ensure that all events (CompEventSource) get
+     * handled before the screen is redrawn or animations updated. So the
+     * image on the screen doesn't lag behind the current mouse pointer
+     * position by more than 1 frame or so.
      */
-    set_priority (G_PRIORITY_DEFAULT);
+    set_priority (G_PRIORITY_DEFAULT + 10);
     attach (ctx);
 
     connect (sigc::mem_fun <bool, CompTimeoutSource> (this, &CompTimeoutSource::callback));