touch-packages team mailing list archive

[Launchpad Bug Tracker <1418081@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package mir - 0.13.1+15.10.20150520-0ubuntu1

---------------
mir (0.13.1+15.10.20150520-0ubuntu1) wily; urgency=medium

  [ Cemil Azizoglu ]
  * New upstream release 0.13.1 (https://launchpad.net/mir/+milestone/0.13.1)
    - ABI summary: No ABI break. Servers and clients do not need rebuilding.
      . Mirclient ABI unchanged at 8
      . Mircommon ABI unchanged at 4
      . Mirplatform ABI unchanged at 7
      . Mirserver ABI unchanged at 31
    - Bug fixes:
      . Can't load app purchase UI without a U1 account (LP: #1450377)
      . Crash because uncaught exception in mir::events::add_touch (LP: #1437357)

 -- CI Train Bot <ci-train-bot@xxxxxxxxxxxxx>  Wed, 20 May 2015 21:20:15
+0000

** Changed in: mir (Ubuntu)
       Status: Triaged => Fix Released

-- 
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 Released
Status in mir package in Ubuntu:
  Fix Released

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