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

Bug #1308345 reported by Daniel van Vugt
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mir
Won't Fix
High
Daniel van Vugt
The Ubuntu Power Consumption Project
New
Undecided
Unassigned

Bug Description

[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.

Changed in mir:
importance: Undecided → High
status: New → Triaged
milestone: none → 0.1.9
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

description: updated
tags: added: regression-update
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

tags: added: performance pm
summary: - [regression] Hidden/occluded surfaces are rendering even when not
+ [regression] Hidden/occluded surfaces are rendering even though not
visible
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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

Changed in mir:
assignee: nobody → Daniel van Vugt (vanvugt)
Changed in mir:
status: Triaged → In Progress
Revision history for this message
Alberto Aguirre (albaguirre) wrote :

"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.

Revision history for this message
kevin gunn (kgunn72) wrote :

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.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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

Changed in mir:
status: In Progress → Won't Fix
milestone: 0.1.9 → none
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.