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.
>
> 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.
>
> But if Display1 doesn't need changing, then Display2 can legitimately call
> swap on the whole DisplayGroup.

Good points, but these are implications of how HWC/multimonitor are driven.
On android, it doesn't cause that much of a performance headache because swap_buffers() can be called independently on each "display buffer"/GL context, and the hwc functions themselves don't block, they just schedule work.

>
> I don't see how I can support this with Qt without some form of
> synchronization between the render threads which share a DisplayGroup. Is that
> a correct conclusion?
>
> If so, it'll be work getting Qt to support this.

Right, so, to rephrase an above comment, this change to DisplayBuffer implicitly gives a hint about how the threads of the compositor should be structured, now that we have a platform that does not prefer 1 thread per monitor, but rather prefers a synchronized submission for all DisplayBuffers.

So, my hope with QtMir and other compositors is that we have MultiThreadedCompositor handle the compositor threads and the compositor notification system, and have the compositors override DisplayBufferCompositor, with the already-existing stipulation that DisplayBufferCompositors have to be threadsafe, as composite() can be called from different threads with different DisplayBuffers.