Merge lp://qastaging/~vanvugt/mir/resize-server-Surfaces into lp://qastaging/mir

PASSED: Continuous integration, rev:1201
http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-ci/338/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/125
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-clang-trusty-amd64-build/122
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/67
        deb: http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/67/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-armhf-ci/67
        deb: http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-armhf-ci/67/artifact/work/output/*zip*/output.zip

Click here to trigger a rebuild:
http://10.97.0.26:8080/job/mir-team-mir-development-branch-ci/338/rebuild

Looks good.

A slight concern:

85 + surface_buffer_stream->resize(size);
86 +
87 + // Now the buffer stream has successfully resized, update the state second;
88 + surface_state->resize(size);

There is an opportunity for inconsistency here, but I am not sure if it has any significant effect:
1. buffer stream gets resized
2. external entity gets surface size which hasn't changed (or has it cached from before, because it hasn't received a notification yet), and makes a decision based on this information
3. external entity gets a new buffer which has size != surface size
4. surface state gets updated

Alexandros,

That inconsistency is something I have planned for right from the beginning.

You cannot solve the inconsistency completely, because that would mean the server has to /wait/ on and rely on the client to fill new buffers quickly. But we don't and shouldn't trust clients.

So what I've done is treat resizes asynchronously. The surface size changes immediately. But its buffers will take a while to catch up (because they're coming from another process that's an unavoidable fact of life). This means there's no blocking and no interruption to what the user sees. Worst case is that you'll be rendering an old buffer size to the new surface size, so might briefly see some scaling happen while the client catches up. I think this is the ideal approach.

Thus, rather than solve the inconsistency which isn't really feasible to solve, we just handle the fact that during rapid resizing the surface size might be different to the buffer size within it. So long as we're aware that's possible and /normal/, it's very easy to handle.

Also, we may choose to clamp instead of scale... as a matter of cosmetics. I'm not sure which looks best, but all existing windowing systems seem to take the clamp approach.

OK.

LGTM (well nothing about *Surface* really looks good but...)