Merge lp://qastaging/~vanvugt/mir/neg into lp://qastaging/mir

FAILED: Continuous integration, rev:2224
http://jenkins.qa.ubuntu.com/job/mir-ci/2611/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-android-vivid-i386-build/790
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-clang-vivid-amd64-build/790
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-vivid-touch/752
    FAILURE: http://jenkins.qa.ubuntu.com/job/mir-vivid-amd64-ci/608/console
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/752
        deb: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/752/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/3881
    SUCCESS: http://s-jenkins.ubuntu-ci:8080/job/touch-flash-device/16983

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

PASSED: Continuous integration, rev:2226
http://jenkins.qa.ubuntu.com/job/mir-ci/2613/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-android-vivid-i386-build/793
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-clang-vivid-amd64-build/793
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-vivid-touch/755
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-vivid-amd64-ci/610
        deb: http://jenkins.qa.ubuntu.com/job/mir-vivid-amd64-ci/610/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/755
        deb: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/755/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/3884
    SUCCESS: http://s-jenkins.ubuntu-ci:8080/job/touch-flash-device/16986

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

Looking at multiwin, I believe you need to apply contrast only on .rgb and leave alpha as is .. or maybe apply it to .rgb/.alpha and *.alpha afterwards, but not sure about the constrast computation.

+ 133 neffects - because of negative inside that MP I stumbled over that term.

Havent thought about the changes to GLRenderer yet.

Unity8 reimplements GLRenderer, so they wouldn't want to pick up our GLRenderer just to have the inverted color rendering. USC doesn't reimplement GLRenderer, but if we're not publishing the header, then this wouldn't help USC either. I'm okay with this change to the proving shell (although, why not try to drive through the public api?), but how does this help USC/U8 implement the feature?

This proposal is not intended to help USC or U8 in their current forms. It's foundational work to demo and support future custom shaders in custom shells that utilize GLRenderer. Which is why I did it on the weekend.

There are many such enhancements I want to see in Mir. And any that are not business driven will be done in my own time. Just as you would see from any community contributor.

PASSED: Continuous integration, rev:2227
http://jenkins.qa.ubuntu.com/job/mir-ci/2627/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-android-vivid-i386-build/816
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-clang-vivid-amd64-build/816
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-vivid-touch/778
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-vivid-amd64-ci/624
        deb: http://jenkins.qa.ubuntu.com/job/mir-vivid-amd64-ci/624/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/778
        deb: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/778/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/3903
    SUCCESS: http://s-jenkins.ubuntu-ci:8080/job/touch-flash-device/17021

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

yes looks better.. abstain for now until I get look at the GLRenderer solution again

I don't have a problem with adding the feature, but I guess I still don't see how adding a feature that USC/U8 cannot use helps with the bug. To rephrase, I don't see this addressing the bug. Is this just proving that a shader can be written to achieve the effect that is requested? (making this a somewhat-related branch, but not a fix to the wishlist request)

For me this branch has a more important purpose than the attached bug; It provides a simple demo for custom shaders in custom shells. It showed me what still needed improving in GLRenderer, so that I may get to my own goal of demonstrating more fancy decoration ideas in the demo shell. I then plan to use those demonstrations to argue for similar ideas in future for Unity8.

So the purpose of our demos should come full circle, from appearing to be toys, but eventually helping to motivate positive change in real projects.

Should at least be unlinked from bug.

> Should at least be unlinked from bug.
Well, it shouldn't resolve the bug at least (could be in the comments)

> So the purpose of our demos should come full circle, from appearing to be
> toys, but eventually helping to motivate positive change in real projects.

I agree, but we're changing mg::Renderer (a non-public interface, because its too strange of an interface to support publicly) So, I guess I'm on-board with the feature, but would rather start driving the public interfaces, as opposed to the privileged internal access that the playground/ servers have.

+1 on not resolving the bug.

Otherwise, it looks fine.

This branch doesn't resolve the bug for Unity8. That's why it's a separate task already.