Comment 6 for bug 1372850

The problem appears to be that we're triggering scene changes at the raw touch event rate (125Hz on Nexus4), and so the compositor never has any hope of keeping up. It will always skip frames.

Robert has a workaround to disable the code, which works when touchspots are disabled. But the problem persists when you enable touchspots.

I suggest the design and implementation of the feature is very overcomplicated and inefficient. Although if I can't get team approval to revert it, we can try to look at ways to make our scene change events groupable, and thus give the compositor a chance of keeping up.

In Compiz I implemented a simple approach that could help. That is to simply delay all compositing by some milliseconds after the change event. This allows multiple events to be grouped and composited in a single frame. Although I'm not sure that would suffice here when we're dealing with touchscreens that generate events hundreds of times per second.

Maybe we can make our compositors' scheduling/scene change logic smarter still some other way... such that a compositor does not have to render at 125Hz to keep up with the change events. I guess the missing piece is that the scene doesn't yet have any method for probing its renderables to ask "are there _really_ any more buffers pending that have not been composited?". Although I'm reluctant to jump in to any solution that adds yet more complexity to the mix.