Merge lp://qastaging/~albaguirre/mir/make-screencast-capture-opaque into lp://qastaging/mir

PASSED: Continuous integration, rev:1613
http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-ci/1568/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-android-utopic-i386-build/112
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-clang-utopic-amd64-build/113
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-utopic-touch/113
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-amd64-ci/87
        deb: http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-amd64-ci/87/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-armhf-ci/85
        deb: http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-armhf-ci/85/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-utopic-armhf/249
        deb: http://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-utopic-armhf/249/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/1377
    SUCCESS: http://s-jenkins.ubuntu-ci:8080/job/touch-flash-device/6974

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/mir-team-mir-development-branch-ci/1568/rebuild

I suggest this perhaps should not be fixed. If we have any nested servers utilizing the alpha channel that's an unacceptable performance hit on anything other than high-end hardware. Fixing this bug just supports people writing very bad graphics code.

Oh, I remember now. We agreed nested servers would sometimes need to be blended for fancy shaped transitions. But we also agreed they must not use the alpha channel during regular usage. So a fix will be required at some stage. But at the same time, it does suggest we have slow-rendering nested Mir servers around that need improving.

(1) There's a performance issue here; glGet functions require a round-trip stalling the pipeline:
57 + glGetFloatv(GL_COLOR_CLEAR_VALUE, old_clear_color);
58 + glGetBooleanv(GL_COLOR_WRITEMASK, old_color_mask);
[http://www.opengl.org/wiki/Common_Mistakes#glGetFloatv_glGetBooleanv_glGetDoublev_glGetIntegerv]
But maybe it's OK in this case since it's immediately before glFinish() which is a definitive round-trip sync anyway.

(2) glClear() in the post_update() function looks like it's almost certainly in the wrong place. It can only work if you assume the compositor recycles the framebuffer, which is a dangerous assumption(?)
74 + make_opaque();
75 glFinish();

(3) Calling glClear() twice per frame is a major bottleneck [1] which should be avoided. How about something like:
void mc::GLRenderer::begin() const
{
    glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE);
    glClear(GL_COLOR_BUFFER_BIT);
    glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_FALSE);
}
...?

[1] https://bugs.launchpad.net/mir/+bug/1170243

(1) Ack - but I didn't want to just change state and not restore it though.
(2) Ack - I just don't know of any better place that only appliest to screencasting though.

(3) That's what I had on the previous MP (https://code.launchpad.net/~albaguirre/mir/render-opaque-background/+merge/218712)
    Except you have to set the clear color since the default has alpha set to 0.0

However, should be messing with the alpha at all in the normal rendering path? Or should we just impose that the compositor will enforce opaqueness once it's done? I think it *NEEDS DISCUSSION* - but I'm leaning towards opaqueness.

In any case the purpose of this MP was to *FOR NOW* limit the opaqueness decision to screencasting only.

OK, after some more thought I do think the previous MP (https://code.launchpad.net/~albaguirre/mir/render-opaque-background/+merge/218712) is a better solution.

Currently mir does not support transparent framebuffers properly anyway (per-pixel alpha in resulting framebuffer is not correct).