Mir

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

Revision history for this message
Kevin DuBois (kdub) wrote :

> " loosing the logic puts us in a worse position if we're ever told to send
> 'occluded' messages to the client."
>
> We already have that need. It should go hand-in-hand with the non-blocking
> swap behavior IMHO.
>
> Clients need to know when their surfaces are no longer visible so they can
> stop their rendering loop - this is either from having a surface that is no
> longer visible in any display or from true occlusion.
> In the Unity8 case this is currently being handled by the app lifecycle since
> we don't currently produce those events.

Yeah, but where the occlusion code is now is not in a good position to notify clients. Compositors should not have the job of notifying clients of their decisions, the clients should get notifications based on things going on with their associated ms::BasicSurface.

This pushes me to think we have to shift occlusion detection to SurfaceStack, as it seems the common place this could be done. The compositors sure have to have a role in submitting what sort of occlusion they should do, but I don't want the compositors slowed down by having to send IPC events.

Now of course, this is tricky, because we could have multiple compositors, but I think can be done as the SurfaceStack gets a bit smarter about what compositors are viewing the SurfaceStack.

« Back to merge proposal