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

[Daniel van Vugt]

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.

[Daniel van Vugt (vanvugt)]

I know for a fact that MultiThreadedCompositor has employed a few different algorithms over the past year or so. And most of them are immune to this problem. So this is a relatively recent (past ~6 months) regression. Can't quite find which revision introduced the regression.

[Daniel van Vugt (vanvugt)]

And there's another apparently separate bug --> LP: #1379685

[Alexandros Frantzis (afrantzis)]

> 1. surfaceA emits a frame, one is scheduled
> 2. surfaceA emits another frame, but still only one is scheduled for compositing

Isn't schedule_compositing() called with num_frames=2 the second time (I would expect buffers_ready_for_compositor() to return 2 the second time, if the first frame hasn't been rendered)?

[Daniel van Vugt (vanvugt)]

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.

[Daniel van Vugt (vanvugt)]

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