Pretty pictures of a stuttering server attached.Notice the CompositingFunctor where ~vector destruction is consuming 30% of the time, due to ~TemporaryCompositorBuffer taking 27% of the time.
I think we need to move the final buffer release/response logic out of the compositor thread one way or another, because blocking the compositor thread is a very visible problem.
On 03/11/14 08:36, Daniel van Vugt wrote:
This bug and its sister bug are driving me crazy: https://bugs.launchpad.net/mir/+bug/1388490 https://bugs.launchpad.net/mir/+bug/1377872 I can see in both cases that the frame rate ceiling is arbitrary and temporary. It has nothing at all to do with the power of the host. And the workaround that fixes the problem in both cases is a bit crazy. I've so far investigated theories around: * buffer lifetimes * Mesa/intel GL batching bugs * lock contention (locks held too long) * power management modes * Mir socket/protocol bottlenecks All the theories have some merit but I am not making progress. If you are (un)lucky enough to be able to reproduce either bug then please join in. More data points are required. - Daniel
mir-demo-shell-google-profile.svg.gz
Description: application/gzip
-- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
