Page MenuHome

correctly draw UI with enabled alpha channel
Needs ReviewPublic

Authored by Christian Rauch (christian.rauch) on May 1 2020, 9:40 PM.

Details

Summary

This is a work-in-progress workaround for the buffer format selection issue on Wayland with Intel Iris GPUs (https://developer.blender.org/D6567#182240).

The workaround enables the alpha channel for the EGL context such that ARGB2101010 is selected instead of XRGB2101010.

The Blender UI is not drawn correctly in this configuration because many colour settings use an alpha value of 0 instead of 1. I was able to trace and rectify some of the colour settings but I was not able to find the origin of colour settings for "3D Viewport" and "Graph Editor". These views, and potentially other UI elements, still use a transparent background.

Could you point me to where the background colour for these remaining views is set?

Diff Detail

Repository
rB Blender
Branch
ui_alpha
Build Status
Buildable 8561
Build 8561: arc lint + arc unit

Event Timeline

Christian Rauch (christian.rauch) requested review of this revision.May 1 2020, 9:40 PM

@Campbell Barton (campbellbarton) @Brecht Van Lommel (brecht) Can you give me a hint where to change the background colour such that the UI will render with the alpha channel enabled?

For the graph editor, see GPU_clear_color in graph_main_region_draw.

To catch all cases I think you'd need the search the entire code for glClearColor and GPU_clear_color, and see in each case if the alpha is correct.

For the 3D viewport I'm immediately sure where the problem is and if it happens for all 3D viewport settings or only some. overlay_background.c and shaders/background_frag.glsl might be a good starting point.

fix remaining UI elements, except 3D view

All 2D UI elements in the general editor types (Shift + F1..F12) should be opaque now.

I was able to set the 3D Viewport background colour via UI_GetThemeColor4fv(TH_BACK, clear_col); in OVERLAY_draw_scene. However, TH_BACK is not the correct colour and I am unable to determine the correct ThemeColorID for the 3D view background.

Which is the correct colour or ThemeColorID for the background in the 3D view?

set square of TH_BACK values

Instead of painting the 3D view with a specific non-transparent colour, I now just made the entire Wayland window opaque.

@Campbell Barton (campbellbarton), @Brecht Van Lommel (brecht) Could you have a look again at this? It would make testing the Wayland frontend much easier.

set opaque window only if alpha channel is used

Campbell Barton (campbellbarton) requested changes to this revision.May 25 2020, 8:15 AM

The changes to source/blender seem fine.

As for ghost/wayland, could this be isolated to the GPU causing the problem?

For example:

  • Add a member to GHOST_SystemWayland::needs_intel_alpha_hack.
  • Set this when initializing GHOST_SystemWayland using glGetString.
  • Add a check in setOpaque that only runs if needs_intel_alpha_hack is true.
  • Remove GHOST_OPENGL_ALPHA define.
This revision now requires changes to proceed.May 25 2020, 8:15 AM

As for ghost/wayland, could this be isolated to the GPU causing the problem?

I don't think we should condition on the GPU for this as it will make the logic and branching more complicated.
This would require a run-time detection of the specific driver that is loaded (as the issue depends on the driver, not the GPU) and we would then enable the alpha channel in the EGL context and the opaque background depending on the driver. When this issue is eventually fixed, the workaround will still be activated on this specific driver.

I would rather enable the alpha channel for all drivers and GPUs to prevent branching conditions and the need to test the two options instead of one. I don't see a drawback from having the alpha channel enabled now that we have an opaque background.

Of course, it would be better if Blender would draw the UI correctly if the alpha channel is used, but I couldn't make this work for the 3D Viewport without defining a specific colour. If someone manages to fix this "UI alpha" issue, we can also remove the opaque background again.

Another alternative to drawing with alpha channel would be to force using an 8bit RGB configuration instead of the automatically selected 10bit RGB configuration.

@Campbell Barton (campbellbarton) Would you insist on the GPU driver detection for enabling the workaround or can this go as is?

The original issue (wrong buffer format selection on Intel Iris) has been fixed in Mesa 20.0.7 (https://www.mesa3d.org/relnotes/20.0.7.html). Ubuntu 20.04.2 will probably use this or a newer version. Do you want to wait until the fix has been released into Ubuntu, or do you want to merge this workaround now and revert later?

In any case, I think the alpha channel corrections for the Blender UI are still valid, independent if the alpha channel is now activated in the EGL context or not.

@Christian Rauch (christian.rauch) it's common enough to do driver checks to enable workarounds in Blender's code.

See gpu_platform_init in source/blender/gpu/intern/gpu_platform.c,
I don't see the down-sides to doing this in the case of wayland, especially since it's for an issue that's for spesific hardware/driver version. Changing the behavior for all GPU's seems unnecessary.

This value can be set once on initializing the wayland system class, for example.

I am really against having different code branches for this and rather make sure that the behaviour is consistent over all GPUs and drivers. I think there is no downside of having this transparent+opaque setting for all GPUs.
Also, keep in mind that this issue is fixed upstream with Mesa 20.0.7, which eventually will make its way into Ubuntu.

Adding a runtime check on the Mesa version will increase the amount of maintainable code in Wayland and the EGL context and is temporary in any case. Once Ubuntu contains the Intel Iris fix, I would revert this workaround. Other distributions (Fedora, Arch) most likely use the newest Mesa anyway.

I am really against having different code branches for this and rather make sure that the behaviour is consistent over all GPUs and drivers. I think there is no downside of having this transparent+opaque setting for all GPUs.

While I follow your reasoning, I don't see that checking the GPU for a workaround would cause code-paths likely to cause a lot of maintenance overhead we. Could get third opinion from someone else who worked on this area.

Note that the situation isn't great even with this patch, as people can accidentally use alpha in ways that don't work on Wayland but do on X11.

While I follow your reasoning, I don't see that checking the GPU for a workaround would cause code-paths likely to cause a lot of maintenance overhead we. Could get third opinion from someone else who worked on this area.

If there is no drawback from using this with Wayland on other GPUs (like performance issues or UI glitches), then I don't see why one would have this extra GPU driver detection :-)

Note that the situation isn't great even with this patch, as people can accidentally use alpha in ways that don't work on Wayland but do on X11.

This workaround is only active for the EGL context when Wayland is used, and also only until Mesa 20.0.7 made its way into Ubuntu. Not having this GPU driver switch also means that any glitches with UI drawing with alpha will be recognised faster.

In any case, the "UI: correctly draw with enabled alpha channel" commit fixes most of the UI alpha drawing issues, except the 3D view for which I could not find the proper colour settings, Maybe you could merge this first before considering the workaround in the Wayland-EGL code. Ideally, the Blender UI would draw correctly no matter if a window alpha channel is used or not.

use 'TH_BACK' colour for 3D Viewport background

I added the colour setting for the 3D viewport again. Empirically, I determined that the 3D viewport background colour on X11+master is close to the square of the values in TH_BACK (57 vs 63). I could not figure out how to truly set the alpha channel to 1 for the viewport.

@Campbell Barton (campbellbarton) If you accept TH_BACK^2 as the viewport background colour, this would make the "opaque" change in the Wayland code obsolete and Blender would show the same UI with or without alpha channel.

I removed the actual workaround since Mesa 20.0.8 will soon be released to Ubuntu 20.04 (https://bugs.launchpad.net/mpv/+bug/1868520). This should fix the buffer format selection from the drier side.

I kept the fixes that correctly draw the Blender UI if the alpha channel is enabled. @Campbell Barton (campbellbarton) Can you check the remaining patches?

source/blender/draw/engines/overlay/overlay_engine.c
453–455 ↗(On Diff #25497)

There are different backgrounds possible than the theme background, and raising by power of two seems like an approximation to the default color management view transform.

The other clear color changes are fine, but this one is too much of a hack.

source/blender/editors/interface/resources.c
1474

Blender convention is to use 1.0f rather than 1 for floating point constants.

Christian Rauch (christian.rauch) added inline comments.
source/blender/draw/engines/overlay/overlay_engine.c
453–455 ↗(On Diff #25497)

This is indeed a "hack" as I couldn't find the proper place where to change this background colour setting. I would appreciate any hints on where this colour setting is located.

If this is not acceptable, then please just skip the commit "UI: use 'TH_BACK' colour for 3D Viewport background" from merging into master. The remaining commits in this pull request are still valid independent of this 3D background "hack".

Christian Rauch (christian.rauch) marked an inline comment as done.

remove 3D Viewport colour, set alpha as 1.0f

I look at where the 3D viewport could be made opaque but couldn't quickly spot where it is. Doing it in gpu_shader_display_transform.glsl works, but that doesn't seem like the correct place either.

@Clément Foucault (fclem) or @Jeroen Bakker (jbakker) would know better how to do this.

The current changes without the 3D viewport fix look good to me though.

The current changes without the 3D viewport fix look good to me though.

I remove that 3D Viewport hack and set the alpha channel to 1.0f. If there is no immediate solution for the setting the viewport alpha value, then I guess this can be merged as it at least solves the alpha drawing glitches with all the other UI elements.