picom
picom copied to clipboard
dccsillag
Alpha blending for image content interpolation / Opacity decreases when windows are moving
Environment
i3-gaps
picom version
Latest commit on your fork
Configuration:
Configuration file
animations = true
animation-stiffness = 500
animation-dampening = 40
#################################
# Corners #
#################################
# Sets the radius of rounded window corners. When > 0, the compositor will
# round the corners of windows. Does not interact well with
# `transparent-clipping`.
corner-radius = 6
# Exclude conditions for rounded corners.
rounded-corners-exclude = [
"window_type = 'dock'",
"window_type = 'desktop'",
];
# Round borders
round-borders = 1
round-borders-rule = [
# CORPL option dark
# "2:class_g = 'Rofi'",
# CORPL option light
"0:class_g = 'Dunst'",
"0:class_g = 'Rofi'",
"2:window_type *= ''",
# CORPL end
];
#################################
# Shadows #
#################################
# Enabled client-side shadows on windows. Note desktop windows
# (windows with '_NET_WM_WINDOW_TYPE_DESKTOP') never get shadow,
# unless explicitly requested using the wintypes option.
#
shadow = false
# shadow = true;
# The blur radius for shadows, in pixels. (defaults to 12)
shadow-radius = 12
# The opacity of shadows. (0.0 - 1.0, defaults to 0.75)
shadow-opacity = 0.5
# The left offset for shadows, in pixels. (defaults to -15)
shadow-offset-x = -6
# The top offset for shadows, in pixels. (defaults to -15)
shadow-offset-y = -6
# Red color value of shadow (0.0 - 1.0, defaults to 0).
# shadow-red = 0
# Green color value of shadow (0.0 - 1.0, defaults to 0).
# shadow-green = 0
# Blue color value of shadow (0.0 - 1.0, defaults to 0).
# shadow-blue = 0
# Hex string color value of shadow (#000000 - #FFFFFF, defaults to #000000). This option will override options set shadow-(red/green/blue)
shadow-color = "#000000"
# Specify a list of conditions of windows that should have no shadow.
#
# examples:
# shadow-exclude = "n:e:Notification";
#
# shadow-exclude = []
# Specify a X geometry that describes the region in which shadow should not
# be painted in, such as a dock window region. Use
# shadow-exclude-reg = "x10+0+0"
# for example, if the 10 pixels on the bottom of the screen should not have shadows painted on.
#
# shadow-exclude-reg = ""
# Crop shadow of a window fully on a particular Xinerama screen to the screen.
# xinerama-shadow-crop = false
#################################
# Fading #
#################################
# Fade windows in/out when opening/closing and when opacity changes,
# unless no-fading-openclose is used.
# fading = false
fading = true;
# Opacity change between steps while fading in. (0.01 - 1.0, defaults to 0.028)
# fade-in-step = 0.028
fade-in-step = 0.025;
# Opacity change between steps while fading out. (0.01 - 1.0, defaults to 0.03)
# fade-out-step = 0.03
fade-out-step = 0.15;
# fade-out-step = 1.0;
# The time between steps in fade step, in milliseconds. (> 0, defaults to 10)
fade-delta = 8
# Specify a list of conditions of windows that should not be faded.
# fade-exclude = []
# Do not fade on window open/close.
# no-fading-openclose = false
# Do not fade destroyed ARGB windows with WM frame. Workaround of bugs in Openbox, Fluxbox, etc.
# no-fading-destroyed-argb = false
#################################
# Transparency / Opacity #
#################################
# Opacity of inactive windows. (0.1 - 1.0, defaults to 1.0)
# inactive-opacity = 1
# CORPL section inactive-opacity =
# 0.9; # dark
inactive-opacity = 0.8; # light
# CORPL end
# Default opacity for active windows. (0.0 - 1.0, defaults to 1.0)
# active-opacity = 1.0
# CORPL option light
active-opacity = 0.95;
# CORPL end
# Dim inactive windows. (0.0 - 1.0, defaults to 0.0)
# inactive-dim = 0.0
# Opacity of window titlebars and borders. (0.1 - 1.0, disabled by default)
# frame-opacity = 1.0
frame-opacity = 0.7;
# Let inactive opacity set by -i override the '_NET_WM_OPACITY' values of windows.
# inactive-opacity-override = true
inactive-opacity-override = false;
# Specify a list of conditions of windows that should always be considered focused.
# focus-exclude = []
# Use fixed inactive dim value, instead of adjusting according to window opacity.
# inactive-dim-fixed = 1.0
# Specify a list of opacity rules, in the format `PERCENT:PATTERN`,
# like `50:name *= "Firefox"`. picom-trans is recommended over this.
# Note we don't make any guarantee about possible conflicts with other
# programs that set '_NET_WM_WINDOW_OPACITY' on frame or client windows.
# example:
# opacity-rule = [ "80:class_g = 'URxvt'" ];
#
opacity-rule = [
"20:class_g = 'i3lock'",
"100:window_type = 'dock'",
"100:name *?= 'Youtube'",
"100:name *?= 'Netflix'",
];
#################################
# Background-Blurring #
#################################
# Parameters for background blurring, see the *BLUR* section for more information.
blur-method = "dual_kawase"
blur-deviation = false
# CORPL section blur-strength =
# 2 # dark
blur-strength = 4 # light
# CORPL end
# Blur background of semi-transparent / ARGB windows.
# Bad in performance, with driver-dependent behavior.
# The name of the switch may change without prior notifications.
# blur-background = false
# Blur background of windows when the window frame is not opaque.
# Implies:
# blur-background
# Bad in performance, with driver-dependent behavior. The name may change.
#
# blur-background-frame = false
# Use fixed blur strength rather than adjusting according to window opacity.
# blur-background-fixed = false
# Specify the blur convolution kernel, with the following format:
# example:
# blur-kern = "5,5,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1";
#
# blur-kern = ""
blur: {
# deviation = 1.0;
background = false;
background-frame = false;
background-fixed = false;
}
# Exclude conditions for background blur.
# blur-background-exclude = []
blur-background-exclude = [
# CORPL option dark
# "window_type = 'dock'",
# CORPL end
"window_type = 'desktop'",
"name *?= 'slop'",
];
#################################
# General Settings #
#################################
# Daemonize process. Fork to background after initialization. Causes issues with certain (badly-written) drivers.
# daemon = false
# Specify the backend to use: `xrender`, `glx`, or `xr_glx_hybrid`.
# `xrender` is the default one.
#
# backend = "xrender";
backend = "glx"
# Enable/disable VSync.
# vsync = false
vsync = true;
# Enable remote control via D-Bus. See the *D-BUS API* section below for more details.
# dbus = false
# Try to detect WM windows (a non-override-redirect window with no
# child that has 'WM_STATE') and mark them as active.
#
# mark-wmwin-focused = false
mark-wmwin-focused = true;
# Mark override-redirect windows that doesn't have a child window with 'WM_STATE' focused.
# mark-ovredir-focused = false
mark-ovredir-focused = true;
# Try to detect windows with rounded corners and don't consider them
# shaped windows. The accuracy is not very high, unfortunately.
#
# detect-rounded-corners = false
detect-rounded-corners = true;
# Detect '_NET_WM_OPACITY' on client windows, useful for window managers
# not passing '_NET_WM_OPACITY' of client windows to frame windows.
#
# detect-client-opacity = false
detect-client-opacity = true;
# Specify refresh rate of the screen. If not specified or 0, picom will
# try detecting this with X RandR extension.
#
# refresh-rate = 60
refresh-rate = 0;
# Use EWMH '_NET_ACTIVE_WINDOW' to determine currently focused window,
# rather than listening to 'FocusIn'/'FocusOut' event. Might have more accuracy,
# provided that the WM supports it.
#
use-ewmh-active-win = true
# Unredirect all windows if a full-screen opaque window is detected,
# to maximize performance for full-screen windows. Known to cause flickering
# when redirecting/unredirecting windows.
#
# unredir-if-possible = true
# Delay before unredirecting the window, in milliseconds. Defaults to 0.
# unredir-if-possible-delay = 0
# Conditions of windows that shouldn't be considered full-screen for unredirecting screen.
# unredir-if-possible-exclude = []
# Use 'WM_TRANSIENT_FOR' to group windows, and consider windows
# in the same group focused at the same time.
#
# detect-transient = false
detect-transient = true;
# ↓↑: So two windows of same program get individually focused, while menues are part of parent.
# Use 'WM_CLIENT_LEADER' to group windows, and consider windows in the same
# group focused at the same time. 'WM_TRANSIENT_FOR' has higher priority if
# detect-transient is enabled, too.
#
# detect-client-leader = true;
detect-client-leader = false
# Resize damaged region by a specific number of pixels.
# A positive value enlarges it while a negative one shrinks it.
# If the value is positive, those additional pixels will not be actually painted
# to screen, only used in blur calculation, and such. (Due to technical limitations,
# with use-damage, those pixels will still be incorrectly painted to screen.)
# Primarily used to fix the line corruption issues of blur,
# in which case you should use the blur radius value here
# (e.g. with a 3x3 kernel, you should use `--resize-damage 1`,
# with a 5x5 one you use `--resize-damage 2`, and so on).
# May or may not work with *--glx-no-stencil*. Shrinking doesn't function correctly.
#
# resize-damage = 1
# Specify a list of conditions of windows that should be painted with inverted color.
# Resource-hogging, and is not well tested.
#
# invert-color-include = []
# GLX backend: Avoid using stencil buffer, useful if you don't have a stencil buffer.
# Might cause incorrect opacity when rendering transparent content (but never
# practically happened) and may not work with blur-background.
# My tests show a 15% performance boost. Recommended.
#
glx-no-stencil = true
# GLX backend: Avoid rebinding pixmap on window damage.
# Probably could improve performance on rapid window content changes,
# but is known to break things on some drivers (LLVMpipe, xf86-video-intel, etc.).
# Recommended if it works.
# This causes closing windows to output data from previous render buffers
# glx-no-rebind-pixmap = true
# Disable the use of damage information.
# This cause the whole screen to be redrawn everytime, instead of the part of the screen
# has actually changed. Potentially degrades the performance, but might fix some artifacts.
# The opposing option is use-damage
#
# no-use-damage = true
use-damage = true;
# Use X Sync fence to sync clients' draw calls, to make sure all draw
# calls are finished before picom starts drawing. Needed on nvidia-drivers
# with GLX backend for some users.
#
# xrender-sync-fence = true
# GLX backend: Use specified GLSL fragment shader for rendering window contents.
# See `compton-default-fshader-win.glsl` and `compton-fake-transparency-fshader-win.glsl`
# in the source tree for examples.
#
# glx-fshader-win = ""
# Force all windows to be painted with blending. Useful if you
# have a glx-fshader-win that could turn opaque pixels transparent.
#
# force-win-blend = false
# Do not use EWMH to detect fullscreen windows.
# Reverts to checking if a window is fullscreen based only on its size and coordinates.
#
# no-ewmh-fullscreen = false
# Dimming bright windows so their brightness doesn't exceed this set value.
# Brightness of a window is estimated by averaging all pixels in the window,
# so this could come with a performance hit.
# Setting this to 1.0 disables this behaviour. Requires --use-damage to be disabled. (default: 1.0)
#
# max-brightness = 1.0
# Make transparent windows clip other windows like non-transparent windows do,
# instead of blending on top of them.
#
transparent-clipping = false
# Set the log level. Possible values are:
# "trace", "debug", "info", "warn", "error"
# in increasing level of importance. Case doesn't matter.
# If using the "TRACE" log level, it's better to log into a file
# using *--log-file*, since it can generate a huge stream of logs.
#
# log-level = "debug"
log-level = "info";
# Set the log file.
# If *--log-file* is never specified, logs will be written to stderr.
# Otherwise, logs will to written to the given file, though some of the early
# logs might still be written to the stderr.
# When setting this option from the config file, it is recommended to use an absolute path.
#
# log-file = "/path/to/your/log/file"
# Show all X errors (for debugging)
# show-all-xerrors = false
# Write process ID to a file.
# write-pid-path = "/path/to/your/log/file"
# Window type settings
#
# 'WINDOW_TYPE' is one of the 15 window types defined in EWMH standard:
# "unknown", "desktop", "dock", "toolbar", "menu", "utility",
# "splash", "dialog", "normal", "dropdown_menu", "popup_menu",
# "tooltip", "notification", "combo", and "dnd".
#
# Following per window-type options are available: ::
#
# fade, shadow:::
# Controls window-type-specific shadow and fade settings.
#
# opacity:::
# Controls default opacity of the window type.
#
# focus:::
# Controls whether the window of this type is to be always considered focused.
# (By default, all window types except "normal" and "dialog" has this on.)
#
# full-shadow:::
# Controls whether shadow is drawn under the parts of the window that you
# normally won't be able to see. Useful when the window has parts of it
# transparent, and you want shadows in those areas.
#
# redir-ignore:::
# Controls whether this type of windows should cause screen to become
# redirected again after been unredirected. If you have unredir-if-possible
# set, and doesn't want certain window to cause unnecessary screen redirection,
# you can set this to `true`.
#
wintypes:
{
tooltip = { fade = true; shadow = true; opacity = 0.75; focus = true; full-shadow = false; };
dock = { shadow = false; }
dnd = { shadow = false; }
menu = { opacity = 0.8; }
popup_menu = { opacity = 0.8; }
dropdown_menu = { opacity = 0.8; fade = false }
};
Steps of reproduction
Drag a window around with your mouse or make it move or resize in any way.
Expected behavior
The opacity stays the same
Current Behavior
Opacity of the window decreases, with differing levels per pixel of dragging. It stops when I stop draging the window or the animation stops. This does not happen with upstream.
I think this has to do with the blending between frames in animations (if this isn't exclusive to resizes). Maybe the interpolation is a bit of?
It's definitely the blending between frames in animations.
What window are you dragging, and does its transparency come from the application itself or does it come from picom? Could you try both cases?
BTW, this is probably a duplicate of https://github.com/dccsillag/picom/issues/17.
Any window with transparency. Both from picom and when the window sets it's own transparency.
Ok, this should be fixed now too with this commit: https://github.com/dccsillag/picom/pull/22/commits/423b82da5a878632a43583c5a7296db49fcb5dc6
This doesn't really solve the issue.
I haven't done the maths/logic yet, but I'm pretty sure there's some way to guarantee that, whenever compositing both pixmaps, the alphas sum up correctly. That's what we should do.
Right now, whenever there is some size change the alpha still jumps.
Correct in case of resize it does but it at least fixes moving transparent windows.
Unless you use XMonad (as I currently do), which apparently sends a whole geometry update when a window starts being moved with the mouse. This means that right when you start moving there's a sudden jump -- after that it's as expected.
So yes, already helps quite a bit, but is a bit far from the solution (and might be a step in the wrong direction, if the true solution really is to change how the two pixmaps are composited)
The moving flickering is resolved for me. Excited to hear more about the solution, if it's composting math 😃.
The idea is the following:
We should check, but I'm pretty sure that the way that the alpha of compositing two colors (r0,g0,b0,a0) and (r1,g1,b1,a1) is a0+a1.
We already have a variable animation_progress which goes from 0 to 1, where 0 is the start of the animation and 1 is the end of the animation.
Now, let (r0,g0,b0,a0) be the color in a pixel in the new pixmap, and (r1,g1,b1,a1) be the color in the corresponding pixel in the old pixmap. If we blend them as follows:
(r0,g0,b0,a0*animation_progress) over (r1,g1,b1,a1*(1-animation_progress))
Then we should get that the final alpha is
a0*animation_progress + a1*(1-animation_progress) = a0*animation_progress + a1 - a1*animation_progress = (a0 - a1)*animation_progress + a1
which is a linear interpolation from a1 to a0, with time animation_progress. Note that this means that (for 0 <= animation_progress <= 1), for any animation time the final alpha is between a0 and a1, and, in particular, if the alpha hasn't changed, that the final alpha is constant.
This shouldn't be too hard to do, we just need to make sure that we are multiplying the pixel alphas instead of just overwriting them when we specify an alpha for process_window_for_painting. We also might want to clamp the alphas.
P.S.: I want to implement this, but I'm a bit short on time RN.
@pijulius I've spotted a bug. When I open context menus (tested on Firefox and Blueman), the window has a opacity of 0. It's spontaneous; sometimes when I restart Firefox (or I just got lucky and this happened just then), the first context menu is visible.
It's not present three commits ago (e528cd76adb8a6dccffed05275ba2e25f70ba262).
@Icelk can you please check this commit https://github.com/pijulius/picom/commit/65703eb16030d593ab550522d80b44e527aedb73
hopefully this will fix it as had it happening with animation set to none for menu windows but this fixes it for me now.
A small weird thing though, when I first open Firefox, the first context menu when I click on the empty tab-strip appears to be animated, from a smaller size to the actual size.
Here is a video: https://youtu.be/aboYFUXlqqw I imagine it's just Firefox spitting out wrong sizes first time it's opened, and then correcting?
@dccsillag Sounds great, and the math checks out. Anything I can do? I’m not too familiar with C, but have experience with rust, another low-level language. Where to use the alpha and hot to get it there might be the hardest part?
@dccsillag Sounds great, and the math checks out. Anything I can do? I’m not too familiar with C, but have experience with rust, another low-level language. Where to use the alpha and hot to get it there might be the hardest part?
If you want to give it a go, the relevant code is in the functions process_window_for_painting and paint_all_new (when process_window_for_painting is called), both in src/backend/backend.c.
But I think the main (and hardest) thing with this is to ensure that when we apply the alpha passed to process_window_for_painting, we do indeed multiply the current alphas and not overwrite them -- otherwise the math doesn't hold.
I'm pretty sure that has to be done on a on-backend basis; the way that the additional alpha is applied is by using one of Picom's own abstractions, an image operation for the backend called IMAGE_OP_APPLY_ALPHA, which is processed by the backend function/method backend->image_op.
While writing this, I ended up opening the relevant gl_image_apply_alpha function present in src/backend/gl/gl_common.c, which is what the GL backends call on a IMAGE_OP_APPLY_ALPHA backend->image_op. This is what it looks like:
static void gl_image_apply_alpha(backend_t *base, struct backend_image *img,
const region_t *reg_op, double alpha) {
// Result color = 0 (GL_ZERO) + alpha (GL_CONSTANT_ALPHA) * original color
auto inner = (struct gl_texture *)img->inner;
glBlendFunc(GL_ZERO, GL_CONSTANT_ALPHA);
glBlendColor(0, 0, 0, (GLclampf)alpha);
GLuint fbo;
glGenFramebuffers(1, &fbo);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fbo);
glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D,
inner->texture, 0);
glDrawBuffer(GL_COLOR_ATTACHMENT0);
_gl_fill(base, (struct color){0, 0, 0, 0}, reg_op, fbo, 0, false);
glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
glDeleteFramebuffers(1, &fbo);
}
~Note the comment at its start -- it looks like we might be golden for the GL backends -- I think I can check xrender in a bit, too.~ nope, I think this is a problem -- if I read this code correctly, what it does is blend the pixmap with a black rectangle on top, where the black rectangle has, as its alpha, the alpha we want to apply. ~Which isn't really correct... so I might have gotten it totally wrong.~ I didn't check glBlendFunc... now I'm just unsure whether we are overwriting the alphas or if we are multiplying them (as the comment says).
Well, regardless, for some reason, this doesn't seem to do the job:
diff --git a/src/backend/backend.c b/src/backend/backend.c
index db481e0..6176f02 100644
--- a/src/backend/backend.c
+++ b/src/backend/backend.c
@@ -421,12 +421,13 @@ void paint_all_new(session_t *ps, struct managed_win *t, bool ignore_damage) {
} else {
if (is_animating && w->old_win_image) {
assert(w->old_win_image);
+ double animation_progress = clamp(w->animation_progress, 0, 1);
process_window_for_painting(ps, w, w->win_image,
- w->opacity >= 1 ? 1.0 : w->animation_progress,
+ animation_progress,
®_bound, ®_visible,
®_paint, ®_paint_in_bound);
process_window_for_painting(ps, w, w->old_win_image,
- 1.0 - w->animation_progress,
+ 1.0 - animation_progress,
®_bound, ®_visible,
®_paint, ®_paint_in_bound);
} else {
What happens is that on the animation ends the transparency is correct, but in the middle of the animation the transparency seems to be quite lower than it should be (even for opaque windows).
This problem is essentially https://github.com/dccsillag/picom/issues/17. The comment that issue points to has some relevant info of past work on this.
I didn't check glBlendFunc... now I'm just unsure whether we are overwriting the alphas or if we are multiplying them (as the comment says).
Something does seem fishy here. The second glBlendFunc might override the first?
The opacity math is correct, but some interpolation thing (that's not linear) in OpenGL might be the issue.
The second glBlendFunc might override the first?
Pretty sure that is the case, if I remember my GL.
The opacity math is correct, but some interpolation thing (that's not linear) in OpenGL might be the issue.
Not sure I follow.
Don’t quote me on this (as I don’t have much experience with OpenGL), but I recall hearing about colour profiles (or modes) which all images are based on. What is mostly used isn’t linear. There might be issues in interpolating alpha if any of those are used in the alpha channel (I think there are profiles with only linear alpha, where the colours aren’t linear). Just saying this might be the cause, if we find nothing else.
I think what you have in mind is blending with gamma correction vs. blending without gamma direction (which I think some people also call linear blending). But that shouldn't be the issue here -- the resulting alpha should still be some interpolation between both of the pixmaps' alphas, and so, when there is no change in the alpha, the window alpha shouldn't change either.
I'll take a careful look at that, though.
Sounds right. Still think your idea about the glBlendFunc is the right path to take.
I think I figured it out (the problem)!
In the math I posted above, I assumed (as I wrote there) that when composing something with alpha a0 with something with alpha a1 we would end up with something with alpha a0+a1.
OpenGL is apparently very customizable in regards to how this is done -- this is controlled precisely by the glBlendFunc function. It appears that for composing textures, picom uses glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA).
Following table 3.3 in https://www.informit.com/articles/article.aspx?p=1616796&seqNum=5 (that's the cleanest "documentation" I was able to find in regards to this), this means that the resulting alpha is actually a0 + (1-a0)*a1 = a0 + a1 - a0*a1 (which actually makes a tad more sense than a0+a1).
Now all that remains is to find out which values of alpha we apply to each window so that the resulting alpha, as calculated above, doesn't change. That is, we need to find functions a(t) and b(t) such that
a(0) = 0, a(1) = 1
b(0) = 1, b(1) = 0
a(t) + b(t) + a(t)*b(t) = 1, for all 0 <= t <= 1.
Let a(t) be some fixed function such that a(0) = 0 and a(1) = 1. We want to find b(t) such that
a(t)*alpha_a + (1 - a(t)*alpha_a)*b(t)*alpha_b = alpha_b + t*(alpha_a - alpha_b)
Solving for b(t), we get
b(t) = (alpha_b + t*(alpha_a - alpha_b) - a(t)*alpha_a) / ((1 - a(t)*alpha_a)*alpha_b).
Note that:
-
t = 1 ==>b(1) = (alpha_b + alpha_a - alpha_b - alpha_a) / ((1 - alpha_a)*alpha_b) = 0 / ((1 - alpha_a)*alpha_b) = 0. (we can consider the case alpha_a = alpha_b = 1 as a separate case, it's easy to solve) -
t = 0 ==>b(0) = alpha_b/alpha_b = 1.
So this seems like what we were looking for. However, it doesn't look simple to implement, since the amount of alpha to apply seems to depend on the individual pixel alphas themselves.
Maybe we should do an approximate version of this instead, say, using the mean value of the alphas of the window as alpha_a and alpha_b?
Note: this "hard to implement" thing is only really an issue for windows whose transparency does not come from picom. In these windows, we have the w->opacity field, which gives us precisely alpha_a and alpha_b.
But we definetely need to solve this for windows with more sophisticated transparency schemes as well.
I can confirm, however, that this math does indeed solve the problem completely -- no bad change in opacity during animation anymore! But I only implemented it using w->opacity to get the pixel alpha values, so the question now is how we could do that more complicated alpha calculation when the alpha values aren't constant for the whole image.
Maybe we should create a new backend operation (or add some new parameter to the already existing compose operation)? Because we might be able to implement that formula directly with things like glBlendEquation and glBlendFunc. But is there some cleaner way?
Shouldn't we have access to a window's final alpha (after opacity effects applied by Picom and the window's own transparency), since Picom uses this to compose the windows?
If we get that value, can't we swap the w->opacity to use that?
Or is this your idea about the new backend operation?
Yes, we kind of have access to that, in the backend.
In the current state of the code, we apply a single alpha value over the whole image -- and we use w->opacity for that, since that is a single value which picom assigns to the whole image.
However, the problem is that a window doesn't have its own alpha; each of its pixmap's pixels has its own alpha. That means that we would need to calculate that thing for each pixel in the pixmap.
If we want to do that, then it has to be done in the backend -- the backend is the only one with access to the pixmap. Additionally, we don't want to just do a loop over the pixels, that would be inefficient compared to, e.g., opengl calls.
I'm starting to have a feeling that we'll only be able to do this in opengl as a "custom blending" if we use shaders (i.e., glBlendEquation and glBlendFunction won't be enough). I don't think using a shader just for this is a good idea.
So here is another idea -- we implement a variation of the backend compose operation which, instead of doing a0 + (1-a0)*a1 blending, does a0 + a1. I know this is easily done with glBlendFunction, just need to check if it's just as doable in xrender. EDIT: I checked, and if I understood xrender code correctly (I think I did), then it should be easy as well.
If we do this, then we can just go back to using (1-animation_progress), animation_progress for the additional alphas and we're done. And since this is just for a crossfade, I think the quality might even be a bit better (because then the blending of the old pixmap and new pixmap become a lerp eased out by the window's spring animations).
Okay, so I'll try to implement this approach -- use animation_progress and 1-animation_progress for the additional_alphas, and, exclusively for this blending, change over to blending with a0+a1 instead of a0 + a1*(1-a0).