Code review comment for lp:~kdub/mir/display-groups

> I understand the motivation for DisplayGroup. The concept will make qtmir's
> multimonitor support complicated however, as QtMir will allocate one QWindow
> per Display, and expects to be able to call swap buffers on each Display
> individually.

Do you mean Display as in mir::graphics::Display? Or rather DisplayBuffer?

> Individuality being important: if the scene on monitor 2 changes, then its
> render loop will spin up, draw and call swap buffers for Display2. However if
> Display2 is part of a DisplayGroup, it would be presumptuous for it to swap
> the whole DisplayGroup.
>
> What if Display1 (part of DisplayGroup too) was also being rendered, but
> finished later than Display2? It can't call swapBuffers on the whole
> DisplayGroup again, so instead need a sync point between the 2 threads where
> both are done, before calling swap.

This problem is a subset of the problem we have with the underlying android API.
So even with this MP the problem still exists.. but it seems slightly simpler, we only need an optional sync point or optional sync time-window? (optional since for nested/offscreen/mesa DisplayGroup : DisplayBuffer will be a 1:1 relation, as I understood)..