Input/event driven clients may freeze indefinitely

[Daniel van Vugt]

Input/event driven clients may freeze indefinitely. This is a more generalized form of bug 1379685 that can happen with any windowed app too.

The issue is:

       if (!ready_to_composite_queue.empty())
           drop_frame(std::move(lock));

may drop the newest available frame in some cases:

   (ready_to_composite_queue.size() == 1 && contains(current_compositor_buffer, buffers_sent_to_compositor))

So when this happens, we're dropping the latest frame without any guarantees that the client will redraw another. Because a perfectly efficient event-driven app will only redraw when something changes (e.g. input event) and won't redraw just because a new buffer is available. So giving a buffer back to the client won't wake it up.

The simple answer is to ensure you only drop frames when it's proven that you're not dropping the newest one. Because the time to the next frame after that is completely unpredictable and indefinite...

       if (ready_to_composite_queue.size() > 1)
           drop_frame(std::move(lock)); // worst case: the newest frame still gets composited.

[Daniel van Vugt (vanvugt)]

mir (0.10.0+15.04.20150107.2-0ubuntu1) vivid; urgency=medium