Mir

[enhancement] support proper per-pixel alpha for alpha-enabled display framebuffers

Bug #1318852 reported by Alberto Aguirre
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mir
Fix Released
Medium
Alberto Aguirre
mir (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Display framebuffers with alpha enabled pixel format are currently assumed to be opaque.

Mir needs to support writing correct per-pixel alpha so that a nested configuration can do per-pixel alpha transition effects between mir sessions.

Tags: enhancement

Related branches

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I'm still not convinced using an alpha channel is right for transitions. More likely you just want to modify surface opacity for blending (which is a feature that does not per-pixel alpha).

summary: - support proper per-pixel alpha for alpha-enabled display framebuffers
+ [enhancement] support proper per-pixel alpha for alpha-enabled display
+ framebuffers
tags: added: enhancement
Revision history for this message
Alberto Aguirre (albaguirre) wrote :

Daniel,

Yes I agree some transitions can be handled by just surface global alpha; however, I think if we are going to expose an alpha-enabled display framebuffer as we do now then we should properly support it, otherwise we should not be creating display buffers with mir_pixel_format_abgr_8888 or mir_pixel_format_argb_8888.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Alberto:

This is untrue: "expose an alpha-enabled display framebuffer as we do now"

1. Our servers don't have any alpha channel by default:
    EGLint const config_attr[] = {
        EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
        EGL_RED_SIZE, 8,
        EGL_GREEN_SIZE, 8,
        EGL_BLUE_SIZE, 8,
        EGL_ALPHA_SIZE, 0, <==== No alpha requested

2. Our clients (those that are smart enough) don't have alpha by default either:
   float mir_eglapp_background_opacity = 1.0f; ====> results in non-alpha pixel format selection

But those playing at home should remember that you don't need an alpha channel in either the server or client to do alpha-blending. You still get working shadows and Alt+mousewheel opacity in demo-shell without the need for an alpha channel in the destination buffer.

Revision history for this message
Alberto Aguirre (albaguirre) wrote :

On 1) I see... however it seems that's for the MESA platform only though.

The android platform can and does expose alpha enabled display framebuffers. I'll investigate why.

And yes of course you can do alpha blending without an alpha channel in the destination buffer. But that's not what this enhancement is about at all.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Note that Mir's current blending function, and the one most graphics code will ever use, does not read-back the destination alpha at all:
         glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

Thus the target buffer will never need alpha... unless we add fancy effects to the contrary later.

Revision history for this message
Alberto Aguirre (albaguirre) wrote :
Revision history for this message
Alberto Aguirre (albaguirre) wrote :
Revision history for this message
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: New → Fix Committed
Changed in mir:
milestone: none → 0.4.0
Changed in mir:
assignee: nobody → Alberto Aguirre (albaguirre)
Changed in mir:
milestone: 0.4.0 → 0.3.0
status: Fix Committed → Fix Released
Changed in mir (Ubuntu):
importance: Undecided → Medium
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.