touch-packages team mailing list archive

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

Yes indeed. I realised that yesterday.

So this bug might be invalid in the presence of BufferQueue, but the
class design safety in isolation should probably still be improved.

** Changed in: mir/0.8
    Milestone: 0.8.1 => None

** Changed in: mir
    Milestone: 0.9.0 => None

** Changed in: mir
       Status: In Progress => Incomplete

** Changed in: mir/0.7
       Status: Triaged => Incomplete

** Changed in: mir/0.8
       Status: Triaged => Incomplete

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

** Changed in: mir (Ubuntu RTM)
       Status: Triaged => Incomplete

-- 
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 0.7 series:
  Incomplete
Status in Mir 0.8 series:
  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