Picom black strange corners

[lukiiimohh]

Platform

Arch Linux

GPU, drivers, and screen setup

VMWare Drivers

Environment

I use kitty, firefox-gnome-theme, and bspwm

picom version

vgit-ce46b

Diagnostic

**Version:** vgit-ce46b

### Extensions:

* Shape: Yes
* XRandR: Yes
* Present: Present

### Misc:

* Config file used: /home/luk/.config/picom/picom.conf

### Backend: glx

* Driver vendors:
 * GLX: Mesa Project and SGI
 * GL: Mesa/X.org
* GL renderer: llvmpipe (LLVM 14.0.6, 256 bits)
* Accelerated: 0

(You are using a software renderer. Unless you are doing this
intentionally, this means you don't have a graphics driver
properly installed. Performance will suffer. Please fix this
before reporting your issue.)

### Backend: egl

libEGL warning: DRI2: failed to authenticate
[ 01/14/23 12:18:25.133 egl_init ERROR ] EGL_KHR_image_pixmap not available.
 Cannot initialize this backend

Configuration:

shadow = true;

shadow-radius = 10;
shadow-offset-x = -10;
shadow-offset-y = -10;
shadow-opacity = 0.6;
shadow-red = 0.0;
shadow-green = 0.0;
shadow-blue = 0.0;

shadow-exclude = [
                    "class_g = 'Polydock'",        
                     "name = 'stalonetray'",
                     "name = 'polybar'",
                     "name = 'plank'",
                     "name = 'Notification'",
                     "name = 'fluxbox'",
                     "class_g = 'bspwm'",
                     "class_i = 'presel_feedback'",
                     "class_g = 'fluxbox'",
                     "class_g ?= 'Notify-osd'",
                     "class_g = 'xfce4-panel'",
                     "class_i = 'POWERPNT.EXE'",
                     "class_i = 'WINWORD.EXE'",
                     "class_i = 'Meteo'"
                  ];

transition = true;
transition-offset = 25;
transition-direction = "smart-x";
transition-timing-function = "ease-out-cubic";
transition-step = 0.028;
transition-rule = [];
fading = true;
fade-delta = 4;
fade-in-step = 0.05;
fade-out-step = 0.05;
shadow-ignore-shaped = false;
inactive-opacity = 1.0;
active-opacity = 1.0;
frame-opacity = 1.0;
inactive-opacity-override = false;
wm-ignore = true;

wintypes :
{
    popup_menu =
    {
        opacity = 1.0;
    };
    dropdown_menu =
    {
        opacity = 1.0
    };
    dnd =
    {
        shadow = false;
    };
    dock =
    {
        shadow = true;
    };
    tooltip =
    {
        fade = true;
        shadow = true;
        opacity = 0.5;
        focus = true;
    };
};

corner-radius = 6;
rounded-corners-exclude = [
  "class_g = 'Polybar'",
]

Expected behavior

This type of corners

Current Behavior

Works only in kitty, firefox is not working see this image. (I put 100 on rounded corners just for you to see what's happening)

Other details

Only happens in firefox

[absolutelynothelix]

it's an issue with the xrender backend. you may try the glx one but it probably won't work well in the vm.

[lukiiimohh]

What's the parameter for calling glx instead of xrender, for example 'rounded-corners: ' I suppose it is 'backend: glx'?

[absolutelynothelix]

backend = "glx"; in the configuration file or --backend=glx in the command line arguments.

[absolutelynothelix]

@yshui, an insight for you: this is the same issue as #342 when we're adding transparent parts to a non-transparent window (that has 24-bit depth). the fix for the #342 is very specific so i can't easily expand it to cover this issue. maybe you will think of a way to fix this gracefully. here is the related code:

picom/src/backend/backend.c

Lines 435 to 483 in 23a2947

	// Draw window on target
	if (w->frame_opacity == 1) {
	ps->backend_data->ops->compose(ps->backend_data, w->win_image,
	window_coord, NULL, window_coord,
	&reg_paint_in_bound, &reg_visible);
	} else {
	// For window image processing, we don't have to limit the process
	// region to damage for correctness. (see <damager-note> for
	// details)
	// The visible region, in window local coordinates Although we
	// don't limit process region to damage, we provide that info in
	// reg_visible as a hint. Since window image data outside of the
	// damage region won't be painted onto target
	region_t reg_visible_local;
	region_t reg_bound_local;
	{
	// The bounding shape, in window local coordinates
	pixman_region32_init(&reg_bound_local);
	pixman_region32_copy(&reg_bound_local, &reg_bound);
	pixman_region32_translate(&reg_bound_local, -w->g.x, -w->g.y);
	pixman_region32_init(&reg_visible_local);
	pixman_region32_intersect(&reg_visible_local,
	&reg_visible, &reg_paint);
	pixman_region32_translate(&reg_visible_local, -w->g.x,
	-w->g.y);
	// Data outside of the bounding shape won't be visible,
	// but it is not necessary to limit the image operations
	// to the bounding shape yet. So pass that as the visible
	// region, not the clip region.
	pixman_region32_intersect(
	&reg_visible_local, &reg_visible_local, &reg_bound_local);
	}
	auto new_img = ps->backend_data->ops->clone_image(
	ps->backend_data, w->win_image, &reg_visible_local);
	auto reg_frame = win_get_region_frame_local_by_val(w);
	ps->backend_data->ops->image_op(
	ps->backend_data, IMAGE_OP_APPLY_ALPHA, new_img, &reg_frame,
	&reg_visible_local, (double[]){w->frame_opacity});
	pixman_region32_fini(&reg_frame);
	ps->backend_data->ops->compose(ps->backend_data, new_img,
	window_coord, NULL, window_coord,
	&reg_paint_in_bound, &reg_visible);
	ps->backend_data->ops->release_image(ps->backend_data, new_img);
	pixman_region32_fini(&reg_visible_local);
	pixman_region32_fini(&reg_bound_local);
	}

[lukiiimohh]

Literally that backend crashed my entire system, I needed tty to restablish the file of picom.conf. So, obviously that is not working

[yshui]

duplicate of #808 ?

[lukiiimohh]

no, because in my case everything works well except the black corners ONLY in firefox

[yshui]

i think we just forgot to enable alpha blending in some cases, maybe for windows with 24-bit visuals.

[absolutelynothelix]

duplicate of #808 ?

i don’t think so.

[tryone144]

@absolutelynothelix The fix for #342 is here: #650 😉

I agree that this is most likely an issue with 24-bit visuals (as it only happens to some windows). Can we reuse decouple_image() when applying the rounded corners to enforce a 32-bit visual?

[lukiiimohh]

So I can do something to solve it, or just wait for you guys!?

[absolutelynothelix]

@tryone144, ikr. i saw the decouple_image function and the comment inside, i've just traced the logic to the beginning (the snippet i've provided). the problem is that decouple_image is not a publicly available backend operation and it's only used when doing the IMAGE_OP_APPLY_ALPHA operation so i can't think of an elegant fix for this issue. in theory, you may do the IMAGE_OP_APPLY_ALPHA operation without changing opacity so it will just force the pixmap to have 32-bit depth, but it's more a hack rather than a proper fix.

So I can do something to solve it, or just wait for you guys!?

unfortunately, no. it's the xrender backend's issue, glx backend doesn't work for you and egl won't work at all (according to the provided diagnostic information).

[tryone144]

i think we just forgot to enable alpha blending in some cases, maybe for windows with 24-bit visuals.

@yshui pretty close. We reused a potentially only 24-bit visual for the temporary picture to which we applied the rounded-corners mask. This made them obviously not transparent. 😄

@absolutelynothelix no need for such a big change. 😉 Since we already create a temporary picture, we can just force it to a 32-bit visual.

Fixed in #1003

[lukiiimohh]

So, then, notify me when it is fixed, thanks for the work, keep up guys!