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