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

Bug #1256702 reported by Michael Terry on 2013-12-01
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mir
Medium
Andreas Pokorny
mir (Ubuntu)
High
Unassigned

Bug Description

Currently nested servers use an opaque background. Which makes having a greeter that shows the user session behind it difficult.

It would make life a lot easier for the greeter if it could specify that the background should be transparent. Either this is something we could opt-into or make it the default if that wouldn't hurt performance.

Related branches

lp:~robertcarr/mir/alpha-for-nested-servers
Rejected for merging into lp:mir
Alan Griffiths: Needs Fixing on 2013-11-04
Daniel van Vugt: Needs Fixing on 2013-11-04
Alexandros Frantzis: Needs Information on 2013-10-30
PS Jenkins bot: Approve (continuous-integration) on 2013-10-30
Kevin DuBois: Needs Fixing on 2013-10-29
Michael Terry: Approve on 2013-10-29
lp:~andreas-pokorny/mir/allow-transparent-server-buffers
Superseded for merging into lp:mir
Alan Griffiths: Needs Fixing on 2013-12-19
Alexandros Frantzis: Pending requested 2013-12-18
Daniel van Vugt: Pending requested 2013-12-18
lp:~andreas-pokorny/mir/pixel-format-utils
PS Jenkins bot: Approve (continuous-integration) on 2014-01-09
Alexandros Frantzis: Approve on 2014-01-09
Daniel van Vugt: Approve on 2014-01-09
Kevin DuBois: Approve on 2014-01-09
Alan Griffiths: Approve on 2014-01-08
Robert Carr (community): Approve on 2014-01-02
Andreas Pokorny: Approve on 2014-01-02
Superseded for merging into lp:mir/0.1
Mir development team: Pending requested 2014-01-02
lp:~andreas-pokorny/mir/add-pixel-format-to-display-configuration
PS Jenkins bot: Approve (continuous-integration) on 2014-01-10
Daniel van Vugt: Approve on 2014-01-10
Alan Griffiths: Abstain on 2014-01-09
Robert Carr (community): Approve on 2014-01-02
Superseded for merging into lp:mir/0.1
Mir development team: Pending requested 2014-01-02
kevin gunn (kgunn72) wrote :

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

Changed in mir (Ubuntu):
importance: Undecided → High
status: New → Triaged
Daniel van Vugt (vanvugt) wrote :

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.

Daniel van Vugt (vanvugt) wrote :

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

Changed in mir (Ubuntu):
status: Triaged → Incomplete
Michael Terry (mterry) wrote :

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.

Changed in mir (Ubuntu):
status: Incomplete → Confirmed
Daniel van Vugt (vanvugt) wrote :

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.

Daniel van Vugt (vanvugt) wrote :

*Or even* just to ensure...

Michael Terry (mterry) wrote :

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.

Daniel van Vugt (vanvugt) wrote :

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.

Michael Terry (mterry) wrote :

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...

Michael Terry (mterry) wrote :

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.

Daniel van Vugt (vanvugt) wrote :

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().

Daniel van Vugt (vanvugt) wrote :

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.

Changed in mir (Ubuntu):
assignee: Robert Carr (robertcarr) → Andreas Pokorny (andreas-pokorny)
status: Confirmed → In Progress
Changed in mir:
assignee: nobody → Andreas Pokorny (andreas-pokorny)
milestone: none → 0.1.3
status: New → In Progress
importance: Undecided → Medium
summary: - Allow a Mir nested server to have a transparent background
+ [enhancement] Allow a Mir nested server to have a transparent background
Changed in mir (Ubuntu):
status: In Progress → Triaged
assignee: Andreas Pokorny (andreas-pokorny) → nobody
tags: added: enhancement
tags: added: nested
Changed in mir:
milestone: 0.1.3 → 0.1.4
PS Jenkins bot (ps-jenkins) wrote :

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

Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
status: Fix Committed → In Progress
Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :
Download full text (6.8 KiB)

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...

Read more...

Changed in mir (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers