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

Those are reasonable questions but are issues I have already encountered and dealt with, so need some explaining...

"Why not sleep before post() instead of prior to it?"
I did, in the first prototype. It was unfortunately complex and only ever prototyped for Mesa. it was disliked by kdub, and I also realised it failed to address the issue of snapshotting the scene late (buffer contents were younger but attributes like window position were not). Sleeping at the end of the frame guarantees scene snapshotting (surface attributes and buffer contents) are never fixed too early.

"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.

"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.

"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.