Comment 0 for bug 1379610

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