Transparency not working when custom-shader is defined

[ryanfelder]

It seems that when I enable a custom-shader, my terminal is no longer transparent.
I can toggle this behavior with a single # character.
I am on Fedora 41, with Nvidia proprietary drivers and a Geforce RTX 3060.

Here is my ghostty config

window-decoration=true  
gtk-titlebar=false  
window-padding-x=8  
window-padding-y=8  
background=#22190B  
foreground=#E1CBA6  
background-opacity=0.7  
#custom-shader=/home/ryan/Programs/ghostty/shaders/bloom075.glsl  

[rhodes-b]

The shader needs to support transparency, shaders draw on top of the background and if they override the background then it will no longer be transparent

[ryanfelder]

Here's something interesting. I used @GlitchedCode 's example as my intro to shaders and started doing some experimenting.
This shader appears to accumulate values from the output of the shader over time until it maxes out whatever channel is non-zero.

void mainImage(out vec4 fragColor, in vec2 fragCoord)  
{  
    fragColor = vec4(0.01,0,0,0.01);  
}  

Transparency does seem to actually work before the mixing channel (or whatever it's properly called) gets overwhelmed by accumulated past values.

I forgot to mention but it's probably relevant, I am in a Wayland session.

@mitchellh Do you mind taking another quick look at this? I have more super basic experimental shaders to demonstrate what I think is some weirdness but the shader above is probably the most interesting example and wanted to cut straight to the chase.

[ryanfelder]

Here are my other experimental shaders...

Pass everything through unchanged... works fine but no transparency.

void mainImage(out vec4 fragColor, in vec2 fragCoord)
{
    fragColor = vec4(texture(iChannel0, fragCoord / iResolution.xy));
}

Manually tweak alpha... strange, it seems to be mixing with white.

void mainImage(out vec4 fragColor, in vec2 fragCoord)
{
    vec4 color = texture(iChannel0, fragCoord / iResolution.xy);
    fragColor = vec4(color.rgb, .5);
}

Fully transparent shader... this works, but if the alpha is anything other than zero, it goes fully opaque... but not white.

void mainImage(out vec4 fragColor, in vec2 fragCoord)
{
    fragColor = vec4(0.0,0,0,0.0);
}

That confused me, because my previous theory was that it wasn't getting the data on what was underneath, and was being given white instead... that's when I tweaked the values of the last shader here and noticed it wasn't being given white, it looked to me like it was being given the correct values but then accumulating them so quickly it basically instantly filled til RGB were all 1.

[ryanfelder]

And here is a video of the curious shader in action

Screencast.From.2025-02-25.10-47-07.webm

[GlitchedCode]

I can confirm @ryanfelder 's findings. Here is a video of a shader from hackr-sh/ghostty-shaders, modified to work with the incoming alpha channel. To visually reproduce the compounding effect i multiplied the fragment output's alpha channel by 0.0000001, and as you can see in the first moments of my recording the background does come through.

Kooha-2025-02-26-12-05-26.mp4

That is not the only problem though. I also tried to selectively force the output's alpha channel to 0 or 1, depending on the input. And it looks like the input uniformly comes in as opaque, with an alpha value of one, as demonstrated in the following video. I lowered my backgound-opacity setting to 0.5 for this test.

Kooha-2025-02-26-12-15-10.mp4

[soanvig]

I experience exactly the same issue. Additionaly, if I apply fading effect (fragColor = vec4(0.4 * fragColor.rgb, 0.4);) I can see "faded" thing accumulating in the background.

On the left: after few "ls" runs, on the right: new window (it is blurred due to glow effect as well, but happens without glow as well)

Which makes me thinking. How that fading effect even works if it has no time variable? That must mean, it intentionally uses that accumulation effect.