[regression] Hidden/occluded surfaces are rendering even though not visible

[Daniel van Vugt]

[regression] Hidden/occluded surfaces are rendering even when not visible. This is a regression of bug 1227739.

Test case:
  1. sudo mir_demo_server_shell &
  2. sudo bin/mir_demo_client_egltriangle -s 100x100 &
     sleep 5 ;
     sudo bin/mir_demo_client_egltriangle -s 200x200 -q &

Expected: The smaller occluded client stops logging its frame rate after 5 seconds when the larger one starts.
Observed: Logging of the frame rate continues.

[Daniel van Vugt (vanvugt)]

Bisected:
------------------------------------------------------------
revno: 1545 [merge]
author: Alexandros Frantzis <email address hidden>
committer: Tarmac
branch nick: development-branch
timestamp: Thu 2014-04-10 20:17:20 +0000
message:
  compositor: Consume buffers of surfaces that are not rendered on screen

  This ensures that eglSwapBuffers() in clients doesn't block if a surface is not
  rendered. Fixes: https://bugs.launchpad.net/bugs/1233564, https://bugs.launchpad.net/bugs/1292306.

  Approved by Alberto Aguirre, PS Jenkins bot.
------------------------------------------------------------

I am aware we had a plan to unblock rendering while the screen is off. Although I disagree with that, it is separate to unblocking rendering while the screen is on. Hidden and occluded surfaces should never render at all regardless of the monitor state. This was bug 1227739 which was resolved last year. We should not reintroduce it if we're serious about conserving power.

[Daniel van Vugt (vanvugt)]

If we are serious and intent on changing the behaviour then we would also delete the occlusion detection logic from src/server/compositor/ because it's now effectively useless. But I'd rather not go down that path.

[Daniel van Vugt (vanvugt)]

I have a plan that I think everyone would find agreeable. Probably won't have any proposals ready today though.

[Alberto Aguirre (albaguirre)]

"If we are serious and intent on changing the behaviour then we would also delete the occlusion detection logic from src/server/compositor/ because it's now effectively useless. But I'd rather not go down that path."

No, that is still useful when the Display Buffer compositors are actually running.

In fact I think we need to send an event to clients signaling their surfaces are no longer visible either from occlusion (so reuse occlusion detection logic) or display off which we currently don't do; the examples can then pause/stop their rendering loops.

As for https://bugs.launchpad.net/mir/+bug/1227739 rendering will be stopped via qtubuntu so there should be no regression of that particular bug.

[kevin gunn (kgunn72)]

i like alberto's idea, callback on occluded surface - and use demo code to vet it.

altho, it is fair to point out, using a side channel is "laggy" in the sense that the client may render a few more frames before actually stopping. altho, one could also argue there may be need (hence why we're moving the responsibility, mir shouldn't know the business of app render states)

@ duflu - on the topic of "I have a plan that I think everyone would find agreeable". Please share the idea with the team or on mir-devel before getting too crazy with the idea spending implementation energy on something that might be a no-go.

[Daniel van Vugt (vanvugt)]

I thought I would have a proposal up already but too many other things got in the way last week.

You only have to use the dummy buffer consumer when the screen is off (arguably not even then). When it's on you can do normal composition/occlusion testing. And the dummy consumer does not need to be woken (hence avoiding this bug).

Weirdly that would make Mir's power usage potentially lower when the screen is on than when it's off. So that would be motivation to implement similar smarts for the screen off case.

Essentially the dumb buffer consumer that was introduced recently just needs to be smarter. That can be done a variety of ways. Although I don't see any need for adding new message types for clients to interpret.

[Daniel van Vugt (vanvugt)]

Won't fix, I think. See: lp:~vanvugt/mir/unocclude