Code review comment for lp:~vanvugt/mir/unocclude

>> > Occlusion detection is designed to block clients that are not visible. That's
>> > it's purpose. If we're serious about making things non-blocking then it makes
>> > no sense to keep it as it only gets in the way (as mentioned here:
>> > https://code.launchpad.net/~vanvugt/mir/judder/+merge/216694)

Occlusion detection can also be used to prevent overdraw. Clearly whether buffers are returned to the client is a different question than whether buffers are part of the composition pass.

This isn't so different than for example an XRender client under Compiz...client rendering isnt blocked by compositor consumption at all (at least not in the serial queue frame consumption style we have)! Still Compiz will choose to not paint occluded windows. We improve this model by enforcing synchronization while clients are painted on screen, and are free to break this lockstep synchronization guarantee when clients are not rendered.

>> Hey I don't mind occlusion logic staying, but it is contradictory to non-blocking efforts. Choose one or
>> the other.

Not if you allow framedropping for unrendered surfaces.