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

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?

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.

In D7599#188858, @Campbell Barton (campbellbarton) wrote:

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.

In D7599#190694, @Christian Rauch (christian.rauch) wrote:

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.

In D7599#191747, @Campbell Barton (campbellbarton) wrote:

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.

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?

In D7599#195228, @Brecht Van Lommel (brecht) wrote:

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.

@Campbell Barton (campbellbarton) @Brecht Van Lommel (brecht) Is this ready to go now?