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

>
> "The vsync period is the minimum we can hope to guarantee"
> False. Proof 1: This branch. Proof 2: Try it with a framedropping client like
> "mir_demo_client_target -n" and you will see one frame latency is noticeable
> and we can visibly do better than one frame latency using this branch.
>

I think we're on the same page here... In a vsync system, we can /guarantee/ that the minimum is one vsync period, but by delaying like in this branch we can reliably get smaller-than-on-vsync period latency. I'm pointing out that sleeping or scheduling is the only way to dance around the limitations that we're given by vsync.

> "Now, this means we have to make some good guesses as to how much to sleep,
> based on the GPU load though, as bad guesses can also increase latency."
> Only partyly true. I have explicitly only applied the optimization to
> bypass/overlays so that there is no GPU GL render load to contend with. And to
> make sure the timing is right I have spent two weeks testing all our devices,
> and the slowest netbooks I can find.

We can't make sure that there's no GPU render load, as the rest of the system could be drawing and waiting on Buffers. An example is unity8/usc... USC knows it hasn't drawn, but doesn't know if U8 or U8-clients have used the gpu.

>
> "Also, we're getting to the tricky part where our latency optimizations are
> dynamic"
> It's not dynamic on Android at least. I discussed that in the description.

Right, they aren't in this branch. Can't sleeping eat up time that the the clients (or clients-of-nested) would want to draw in? so USC doesn't miss the deadline, but the clients might start to. Having a feedback system that adjusts the amount of sleep seems like it could be helpful.