[enhancement] Allow a Mir nested server to have a transparent background

racarr, not sure you're the right person....might determine if anpok should take

This is high risk with respect to performance.

Blending is slower than not blending. And preventing the occlusion optimizations (and bypass) from kicking in is much slower again.

If it's a temporary thing like during transitions then that's probably OK. Otherwise it should be off the table. Because we're potentially talking about throwing out all the performance work that's been done so far, if we implement this.

As discussed in London, we need design docs/pics/video to see the amount and type of effects we're talking about.

Daniel, the design docs is basically what we have now. I could dig up the original designs for 13.10, but you can see them on the device today. The alpha is needed to keep the same look and feel when unlocking after we implement a split greeter process. To be able to show the session beneath the greeter as we slide away.

You say we throw out all the performance work. Is that because all our optimization work assumed opaque backings or are you saying transparency is inherently unoptimizable?

This can be opt-in for greeter only, so we'd only affect the greeter.

If this is just too risky for Mir, we can go down another road and keep screenshots on the device to show. That has its own complexities, but could be done. I had assumed a transparent Mir would be better.

Mir team came to the conclusion last week that we would all like to see something from design to better describe the exact requirements. Because we're concerned that you might (unlikely but might) be requesting things you don't need in the end.

Essentially, our only requirement for accepting this feature is to ensure session surfaces do _not_ have alpha channels after the login. Or ever just to ensure that user sessions don't ever have alpha channels. So if it's just the greeter then that's probably cool.

Yes, my concern is around bypass and occlusion optimizations. Both of those are instantly disabled by having a translucent surface on top. Which is fine if it's only the greeter.

*Or even* just to ensure...

I'm very confused about the design comments. I just want to re-achieve exactly what we have today. I'm not chasing some crazy new design. Would the Mir team feel better if Katie (the design person handling the greeter) confirmed the see-through-swipe on the greeter?

And yes, only the greeter would need this. This bug is about requesting a way to opt-in to alpha.

That's where I'm confused. "exactly what we have today" does not involve any transparency. Or are you counting the static rendering on the login screen that has a transparent appearance?

I get that a "swipe through" would add a new requirement for a transparent greeter surface (based on my imagination of what "swipe-through" means). But we need to see the design to verify if surface opacity is adequate or per-pixel alpha (shape) is required.

Regardless, if we limit blending to just the greeter surface(s) then I have no complaints.

Daniel, lock your phone. Turn it back on and you see the greeter. Swipe from the right, and you see the dash underneath as you swipe.

Now imagine that the greeter and the dash are two separate processes, run by two separate users. That's the case I'm trying to support. And that's the case that regresses being able to see the dash underneath the greeter right now.

But I'm actually thinking it's easier to go down the screenshot route with these backgrounds rather than actual opacity. That way we wouldn't regress the feature if the user can't be logged in (encrypted home or multi-user scenarios).

So hold on a sec while I experiment with that...

Oh god, nevermind. I forgot about the situation of launching an app while we show a lockscreen on top. We'll still need the alpha mode. Screenshots won't be sufficient.

OK, I just tested locking with the swipe on both phone and tablet. There's no blending anywhere at the moment so I still have to use my imagination.

I imagine you'd only need the greeter fading out, so only the greeter needs some transparency. And more importantly, it looks to me like we'd only have to give the greeter a uniform level of transparency as it fades out. You don't need and shouldn't use an alpha channel to do that. Just let the compositor do it by setting: surface->set_alpha(amount)

The requirement is now even less clear to me than it was before. Now I've seen the animation (without blending) I can't imagine why you'd need an alpha channel to implement the blending/fadeout. The Mir compositor will already happily blend RGBX surfaces via set_alpha().

Oh, I forgot... it's a whole server that needs fading out if we're nesting.

So new functionality is likely required. But you should try to implement a single set_alpha() (or set_opacity; see bug 1236224) rather than concerning yourself and others with the performance issues of an RGBA pixel format.

Fix committed into lp:mir/devel at revision None, scheduled for release in mir, milestone Unknown

This bug was fixed in the package mir - 0.1.4+14.04.20140204-0ubuntu1

---------------
mir (0.1.4+14.04.20140204-0ubuntu1) trusty; urgency=medium

  [ Daniel van Vugt ]
  * New upstream release 0.1.4 (https://launchpad.net/mir/+milestone/0.1.4)
    - Fixed snapshotting and flicker problems for Unity8 on various Nexus
      devices.
    - Enhanced reporting of performance information:
      . Report input latency in InputReport/InputReceiverReport.
      . Added a CompositorReport for logging compositor performance and state.
    - Added a new package "mir-utils" containing new tools:
      . mirping: Displays round-trip times between client and server
      . mirout: Displays the monitor layout/configuration details
    - Added GL texture caching to improve performance when multiple surfaces
      are visible.
    - Added opacity controls to mir_demo_server_shell
    - Mir server ABI bumped to 13. Client ABI bumped to 5.
    - Removed lots of Android headers, replaced by build-dep: android-headers
    - Added support for translucent nested servers.
    - tests: Fix unitialized values and incorrect fd closing loops
    - Fix unitialized values and incorrect fd closing loops.
    - client: Add basic MirScreencast C API.
    - config: start moving default values for config options from all the
      call sites to the setup
    - tests: Provide a helper for running clients with a stub ClientPlatform.
    - android: split out HWC layers into their own file and add a
      mga::CompositionLayer type that depends on the interface mg::Renderable.
    - client: Add basic MirOutputCapture class.
    - client: Don't create mesa ClientBuffer objects from invalid
      MirBufferPackages.
    - Optimize surface resizing to avoid doing anything if the dimensions
      are unchanged.
    - SwitchingBundle - add operator<< for debugging.
    - support hwcomposer 1.2 for android 4.4 on nexus 4 (which needs hwc1.2
      support). This patch adds hwc1.2 device construction, as well as progs
      the 'skip' layer in HWC to the buffer properties of the framebuffer.
    - demo-shell: Add simple keyboard controls to rotate outputs; Ctrl +
      Alt + <arrow-key>. Fixes: https://bugs.launchpad.net/bugs/1203215.
    - frontend: exposing internals of the RPC mechanism to enable custom
      function calls to be added.
    - Make udev wrapper into a top-level citizen
    - compositor: ignore double requests to start or stop the
      MultiThreadedCompositor.
    - Add DisplayBuffer::orientation(), to tell the Renderer if we need it
      to do screen rotation in GL (for platforms which don't implement
      rotation natively) Fixes: https://bugs.launchpad.net/bugs/1203215.
    - graphics: add an post_update function that takes a list of renderables
      to the display buffer. This will let the display buffer take advantage
      of full-surface overlays on android.
    - android-input: Improve debug output
    - the stock qcom 8960 hwcomposer chokes on getDisplayAttributes if the
      submitted arrays are not at least size 6. patched the qcom android 4.2
      hwcomposer driver on the ubuntu touch images to work properly, but
      causes us problems with in-the wild...