Update: tracked this down to a priority problem with mutter restacking being triggered out of clutter events and am working on a patch.

Created attachment 144029 [details] [review]
Use "later functions" to fix priority problems with Clutter redraw

There was a problem where if, for example, a restack was triggered
out of a clutter event handler, then after Clutter processed the
events, it would proceed immmediately on to repaint the stage without
ever returning control to the GLib main loop. So even though we
had an idle handler installed with a higher priority than the
Clutter stage repainting the clutter stage repainting would happen
first and we'd get a wrong frame.

Fix this by introducing the idea of "later functions", which abstract
the idea of "doing something later" away from g_idle_add() and use
a combination of GLib idle functions and Clutter "repaint functions"
to get our callbacks triggered at the right time, even when they
are installed from a clutter event handler.

https://bugzilla.gnome.org/show_bug.cgi?id=596334

This also resolve a FIXME where MUTTER_PRIORITY_BEFORE_REDRAW
could starve stage repainting.

I have tested the patch and looked through it pretty thoroughly.  Everything runs and looks sane to me.  This question is from my inexperience with clutter, but would it make any sense to integrate the run_repaint_laters into the mutter_repaint_func we already have in compositor.c?  This approach would keep the clutter specific code split out into the compositor portion of mutter.

Comment on attachment 144029 [details] [review]
Use "later functions" to fix priority problems with Clutter redraw

Thanks Owen, this is great.

(Jon we do not need worry about keeping Clutter confined to the compositor only, now that we have decided not to support multiple compositing backend. Also in this particular case, having a centralized scheduling solution in mutter is highly desirable.)

Pushed the patch. I think keeping the 'scheduling' code together makes more
sense then keeping the 'uses clutter' code together.

One slightly weird thing about Clutter is that repaint functions are global
not per-stage. I'm not sure that's right. If you had multiple monitors
(especially on different cards), they might have different VBlank, so really
you should have a stage per monitor and repaint per monitor with different
timings.

That's really way beyond anything we are handling now.

Attachment 144029 [details] pushed as 3508c4a - Use "later functions" to fix priority problems with Clutter redraw