Merge lp://qastaging/~kdub/mir/nested-db-link-to-streams into lp://qastaging/mir

PASSED: Continuous integration, rev:2484
http://jenkins.qa.ubuntu.com/job/mir-ci/3521/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-android-vivid-i386-build/2053
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-clang-vivid-amd64-build/2052
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-vivid-touch/2003
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-vivid-amd64-ci/1518
        deb: http://jenkins.qa.ubuntu.com/job/mir-vivid-amd64-ci/1518/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/2003
        deb: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/2003/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/4936
    SUCCESS: http://s-jenkins.ubuntu-ci:8080/job/touch-flash-device/19615

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/mir-ci/3521/rebuild

281+TEST_F(NestedDisplayBufferTest, post_optimized_success)

"post_optimized_success" is not a very clear test name. It is worth considering the "given/when/then" rule. (E.g. http://martinfowler.com/bliki/GivenWhenThen.html)

given_an_optimizable_stream_when_post_if_optimizable_then_result_is_success

Or more succinctly:

given_an_optimizable_stream_post_if_optimizable_succeeds

Actually, I misunderstood the test:

when_linked_with_a_stream_post_if_optimizable_succeeds

39+ //validate that we have a host-allocated stream for every renderable we're given
40+ for(auto const& renderable : renderables)
41+ {
42+ auto buffer = renderable->buffer();
43+ auto stream_it = std::find_if(streams.begin(), streams.end(),
44+ [&buffer](HostStream* stream){ return buffer_is_current_in_stream(*buffer, stream); });
45+ //if we have any stream that needs to be rendered but we don't have a stream associated
46+ //we can't passthrough the render
47+ if (stream_it == streams.end())
48+ return false;
49+ }
50+
51+ //TODO: work out how to submit changes synchronously to the client API
52+ for(auto const& renderable : renderables)
53+ {
54+ //TODO: arrange the surfaces via the api according to how RenderableList is structured
55+ auto buffer = renderable->buffer();
56+ auto stream_it = std::find_if(streams.begin(), streams.end(),
57+ [&buffer](HostStream* stream){ return buffer_is_current_in_stream(*buffer, stream); });
58+ (*stream_it)->swap();59+ }

I've not thought it through, but this code has the ugliness I associate with choosing the wrong data structure (or algorithm).

> I've not thought it through, but this code has the ugliness I associate with
> choosing the wrong data structure (or algorithm).

Fair enough. At a high level though, the linkage between the BufferQueue and the DisplayBuffer is needed. The BufferQueue has to get its buffers from MirBufferStream, and the DisplayBuffer has to sort and arrange those streams to paint the desired picture.

It does become nicer if the client isn't so locked into its choices of buffers to use (currently the client has 1 buffer it can use). If the client could allocate more than one buffer, it could simply use those as the buffers in BufferQueue, and mgn::DisplayBuffer could figure out which which buffer to set as the 'active one' when it goes to post, as well as arrange appropriately.

Maybe I'll explore that route a bit more.