Code review comment for lp:~vanvugt/mir/predictive-bypass-2

> I did consider and wanted to do it in the compositor too. However two major
> factors make that impractical:

It sounds like all three of us think the right place is the compositor.

At a minimum we ought to think about what change is needed to make that possible. (You're ahead of me here as I've not worked it through in any detail.)

> 1. In a single algorithm you need to (a) know that bypass/overlays are in
> use and (b) sleep at the _end_ of the post function. That used to be easy but
> the introduction of posting via DisplayGroup outside of
> DisplayBufferCompositor has made it unworkable.

You keep saying that we need to sleep *at the end of post()* am I missing something? Or is that just a proxy for delaying the start of the next composite cycle for that output?

The reason I ask is that compositing is already scheduled based on triggers from scene changes/buffer posts and that logic seems the right place to incorporate any delay.

> 2. Ideally the algorithm should vary timing based on the refresh rate of the
> display, and also disable itself in clone mode. I do all that for Mesa
> already, but it would be impossible to do in the compositor logic because you
> have know knowledge of the output devices there. Only in the DisplayBuffer.

Yes, we've discussed that some timing information would need to be fed into compositor scheduling. But why can't that be provided by the DisplayBuffer?