touch-packages team mailing list archive

[PS Jenkins bot <ps-jenkins@xxxxxxxxxxxxxxxxxxx>]

Fix committed into lp:mir at revision None, scheduled for release in
mir, milestone 0.12.0

** Changed in: mir
       Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to mir in Ubuntu.
https://bugs.launchpad.net/bugs/1418081

Title:
  Compositing is triggered continously and needlessly when there are
  occluded surfaces with available buffers

Status in Mir:
  Fix Committed
Status in Mir 0.11 series:
  Triaged
Status in mir package in Ubuntu:
  New

Bug description:
  Because of recent changes in the way the MultiThreadedCompositor is
  triggered (or rather retriggered) [1], when the
  DisplayBufferCompositor doesn't render (e.g. because it's occluded) a
  non-hidden surface that has available buffers, compositing is
  retriggered continuously at full rate, even when nothing else changes
  on screen.

  To test this, run the proving server:

  $ sudo bin/mir_proving_server --compositor-report log

  then start a client and drag the client offscreen. The compositor log
  should report that the compositor has a frame rate of max(client
  frame, FDP) (FDP=value related to our frame droping policy). However,
  you will see that it's instead rendering at 60FPS.

  As an extreme (but not unusual) example of how problematic this
  behavior can be, perform the following:

  1. Change an example client to render at ~1 FPS (e.g. add sleep(1) in it's main loop).
  2. Perform the previous experiment with that client

  When the client surface is visible, the compositor is triggered at a
  rate of 1FPS. The same should be true when the surface is dragged off
  screen, but instead we get a full compositing rate of 60FPS.

  [1] https://code.launchpad.net/~vanvugt/mir/fix-
  buffers_ready_for_compositor/+merge/247124

To manage notifications about this bug go to:
https://bugs.launchpad.net/mir/+bug/1418081/+subscriptions