Mir

Activity log for bug #1396006

Date Who What changed Old value New value Message
2014-11-25 07:50:28 Daniel van Vugt bug added bug
2014-11-25 07:50:44 Daniel van Vugt mir: milestone 0.10.0
2014-11-25 07:51:41 Daniel van Vugt description 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. 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.
2014-11-25 09:05:37 Daniel van Vugt mir: assignee Daniel van Vugt (vanvugt)
2014-11-25 09:57:27 Daniel van Vugt mir: status Triaged In Progress
2014-11-25 10:46:27 Daniel van Vugt branch linked lp:~vanvugt/mir/unfreeze
2014-11-27 09:47:26 Daniel van Vugt branch linked lp:~vanvugt/mir/unfreeze-2
2014-12-03 18:08:31 Launchpad Janitor branch linked lp:mir
2014-12-04 01:55:03 Daniel van Vugt branch unlinked lp:mir
2014-12-04 02:13:07 Daniel van Vugt mir: status In Progress Fix Committed
2015-01-08 18:09:22 Launchpad Janitor branch linked lp:ubuntu/vivid-proposed/mir
2015-01-09 02:37:41 Daniel van Vugt mir: status Fix Committed Fix Released
2015-01-09 02:37:47 Daniel van Vugt bug task added mir (Ubuntu)
2015-01-09 02:46:15 Daniel van Vugt mir (Ubuntu): importance Undecided High
2015-01-09 02:46:15 Daniel van Vugt mir (Ubuntu): status New Fix Released