Code review comment for lp:~kdub/mir/fix-1369763

> Thanks for looking at this. Just wondering; if you're disabling overlays for
> anything that's interval 0 on the server side and we hope to make everything
> on the server side interval 0 (when interval 1 becomes a function of the
> libmirclient), then won't we need to revert this? Would it not just be a
> better idea to leave the bug unresolved until a final solution is feasible?
>

Once we have dropping-only, the server won't really have a concept of 'swapinterval' anymore (which makes it simpler there). We will probably be best to remove the Renderable::swap_interval information.

> By landing this now, we create a regression that's worse than the bug itself.
> That is a future mirserver will never overlay unless we remember to also
> revert this change.

Its not a regression once it lands, its only a regression if we forget how this works when we change the submission mode in the future. I can keep tabs on it so that when we switch to dropping-only, we will change the behavior. Nested passthrough's behavior will have to change even more when that part of the system is reworked.

Its useful now for fixing android support for this option, and the interval information is needed for nested passthrough to prevent loss of swapinterval 0 on passthrough clients.