touch-packages team mailing list archive

[Daniel van Vugt <daniel.van.vugt@xxxxxxxxxxxxx>]

*** This bug is a duplicate of bug 1395581 ***
    https://bugs.launchpad.net/bugs/1395581

This is being dealt with more accurately as bug 1395581 now.

** This bug has been marked a duplicate of bug 1395581
   Double-buffered surfaces may lag or freeze if event driven and not constantly redrawing

-- 
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/1379610

Title:
  [regression] MultiThreadedCompositor fails to schedule sufficient
  frames and may lag at random times

Status in Mir:
  Incomplete
Status in mir package in Ubuntu:
  Incomplete
Status in mir package in Ubuntu RTM:
  Incomplete

Bug description:
  MultiThreadedCompositor fails to schedule sufficient frames in a
  mostly-idle single surface scenario:

  1. surfaceA emits a frame, one is scheduled
  2. surfaceA emits another frame, but still only one is scheduled for compositing
  3. We composite only one frame (frames_scheduled == 1)
  4. System is idle for some unknown time, with no compositing scheduled but surfaceA has its 2nd frame rendered that we're not seeing.

  The problem is:

      void schedule_compositing(int num_frames)
      {
          std::lock_guard<std::mutex> lock{run_mutex};

          if (num_frames > frames_scheduled)
          {
              frames_scheduled = num_frames;
              run_cv.notify_one();
          }
      }

  If a surface only emits schedule_compositing(1) but does it multiple
  times per compositor frame, then the second and subsequent frames
  won't get scheduled. This can happen for surfaces that are triple (or
  higher) buffered; i.e. any Mir client right now.

  If correct, this would explain bug 1295851 but I will keep them
  separate while we're not 100% sure.

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