[Bug]: Conky fake transparency doesn't work with xfdesktop (XFCE)

[pitsi]

What happened?

Almost 2 months ago, I made a fresh debian unstable installation on a laptop. I installed all my apps there, including conky, and I transfered my .conkyrc (the one I use for more than a decade now) to it. After that, I edited the conky.text part to correct stuff that is related to the hardware changes from the one system to the other (the sensors basically),

When conky runs on xfce though, its background is completely black. For that reason, I also installed openbox there (the wm i use on my main pc since 2009 when xfce was light years behind gnome and kde) and conky is transparent there.
As suggested by other online users online with similar issues, also tried setting own_window_argb_visual to true, but nothing changed. As a sideeffect, this variable made conky have a black background on openboox too.
Setting own_window_type to normal did not change anything too.

Compositing on xfce is and will remain disabled, I can post a screenshot of the whole desktop if needed, and I have omitted the conky.text part of my config because it is irrelevant with the issue.

Version

1.21.6

Which OS/distro are you seeing the problem on?

Debian

Conky config

conky.config = {
    alignment = 'bottom_right',
    background = true,
    border_width = 0,
    cpu_avg_samples = 2,
    default_color = 'ghost white',
    default_outline_color = 'black',
    default_shade_color = 'black',
    double_buffer = true,
    draw_borders = false,
    draw_graph_borders = true,
    draw_outline = false,
    draw_shades = false,
    font = 'ITC Avant Garde Gothic Pro:size=16',
    font1 = 'ITC Avant Garde Gothic Pro:size=14',
    gap_x = 0,
    gap_y = 40,
    no_buffers = true,
    out_to_x = true,
    own_window = true,
    own_window_class = 'Conky',
    own_window_type = 'desktop',
    own_window_transparent = true,
    own_window_hints = 'undecorated,below,sticky,skip_taskbar,skip_pager',
    show_graph_range = false,
    show_graph_scale = false,
    update_interval = 1.0,
    use_xft = true,
}

Stack trace

No response

Relevant log output

No response

[pitsi]

If it helps, here is the terminal output when it is run on xfce

conky: desktop window (0x2fe) is root window
conky: window type - desktop
conky: drawing to created window (0x1800001)
conky: drawing to double buffer
conky: forked to background, pid is 1495
conky: FOUND: console
conky: FOUND: ncurses
conky: FOUND: file
conky: FOUND: x11
conky: FOUND: wayland
conky: 'xfce' x11 session running 'XFCE' desktop

and here is when it is run on openbox

conky: desktop window (0x53a) is root window
conky: window type - desktop
conky: drawing to created window (0xc00001)
conky: drawing to double buffer
conky: forked to background, pid is 747
conky: FOUND: console
conky: FOUND: ncurses
conky: FOUND: file
conky: FOUND: x11
conky: FOUND: wayland
conky: 'lightdm-xsession' x11 session running '(null)' desktop

[Caellian]

Your use of config is weird to me: you use own_window_transparent which doesn't work (well) without a compositor you say you won't enable, then use an opaque default_color. own_window_argb_visual requires you to use a compositor (e.g. picom) as specified in documentation.

How do you want the window to be displayed?

[pitsi]

Is an old screenshot from my desktop, i.e. not the laptop which runs xfce and has the issue, enough to show you what i mean? If so, here you are.

It's openbox without any compositing manager and the entire setup (conky + openbox etc) will soon be 15 years old.

[Caellian]

Sorry, my bad, misunderstood default_color to mean background, not text color. I did some more digging.

You need to use normal window on XFCE because it's got its own desktop window. Use own_window_transparent = true and that requires own_window_argb_visual = true as the docs specify. As I said before own_window_argb_visual requires a compositor to work properly, and xfwm4 handles compositing on its own so installing picom shouldn't be needed.

Default xfce4 install with normal window, own_window_transparent = true and own_window_argb_visual = true, without separate compositor running:

_{None of the other settings should matter.}

I'm closing this as "can't reproduce", but feel free to continue the discussion in case the above settings don't work for you.

[pitsi]

Without enabling xfce's compositor, because that is the goal, I changed/added these

    own_window_type = 'normal',
    own_window_transparent = true,
    own_window_argb_visual = true,

but the background remains black. Enabling the compositor fixes it though.

One interesting thing I found. When setting own_window_argb_visual to false the text does not show unless I logout and log back in. The bars do show up though.

p.s. Please excuse any delays in answering. Some personal issues have arised since yesterday morning that I posted for the last time here.

[Caellian]

You must enable a compositor, either the default xfwm one or install picom.

You can't expect compositing (i.e. process or technique of combining visual elements from separate sources into single images) to happen without enabling a compositor.

You're effectively asking "how do I make a pizza without dough". It's not going to happen.

When a WM draws a window, the pixels shown on the screen must be read from that window's output buffer, and filling that buffer with background content requires a compositor so the window can ask the compositing system what's composited behind the window. If you don't do that, the window can either be a solid color or use a stale buffer.

Besides that you can only draw a carefully positioned crop-out of your background image (though you'll have to use cairo from lua for that) - which will be much slower than simply using a compositor which does precisely that for all windows with transparency.

[pitsi]

I understand what you say, but this specific config has been making a transparent conky for me since since gnome was on 2.2x version (which was more than 15 years ago), and without any compositor running, ever.

What else do you want me to reproduce it on? I can do it on any simple desktop enviroment, like lxde, lxqt etc, or window manager, like fluxbox, and provide screenshots.

[Caellian]

I understand what you say, but this specific config has been making a transparent conky for me since since gnome was on 2.2x version (which was more than 15 years ago), and without any compositor running, ever.

Right, but check your assumptions. Gnome uses gnome-shell as a WM which has its own compositor. Most DEs come with a compositor baked in. Coincidentally XFCE allows you to disable it, but don't expect transparency to work without it because it's a prerequisite.

In order to do what you want to do a compositor must be present. Conky never had some hack that got around this (EDIT: It does in fact try to copy root pixel buffer), and implementing it at this point for X11 doesn't make much sense because all modern desktops are expected to have some sort of compositing for various reasons.

Without compositors, transparent windows have artifacts from moving other windows over them:

That's how things have always been. That's why applications clear their buffer every draw frame. If you had it working, you were running a compositor in the background without knowing it or the WM was updating all windows every frame (very unlikely) which is worse performance-wise.

[pitsi]

Before I start with the... history lesson, I want to say that all those days I am trying to capture a video that shows how conky is drawn when xfce starts, because I am sure it will help identify the issue. From my point of view: xfdesktop starts and draws the wallpaper, then conky itself on a black window (the root window?), then xfdesktop redraws itself over it and then conky draws itself above it. This is a smal video of what happens, but because everything happens in less than a second, please watch it in slow motion and you will see what I mean. Also note that the first part where xfdesktop draws the wallpaper is not visible. No idea why, but I did try to capture it too and failed many times.

output.mp4

This behavior reminded me of this issue kde and conky had back in the days of kde 4, where it drew itself in the root window and plasma-desktop drew over it.
https://web.archive.org/web/20120426022458/http://techknack.net/conky-transparency-fix-for-kde4/

For that reason, I killed both xfdesktop and conky, set my wallpaper with feh on the root window and run conky again. The result? A perfectly transparent conky without compositing, just like the one in openbox! Now I am sure that xfdesktop and conky do not play well together. Any ideas why? Screenshots upon request.

History lesson.
When I say 15 years ago, I am dead serious about it. 15 years ago, i.e. in September 2009, gnome was on 2.28. Gnome-shell has always been always a part of gnome 3 and gnome 3 was not released until 2011.
https://en.wikipedia.org/wiki/GNOME#Release_history

So yea, I did have gnome without compositing and I am happy if it shows my age. And since I have never found a real use for compositing, I think that fake transparency is good enough when needed, like now.

[pitsi]

Time for some screenshots, because I tried the kde4 workaround and it worked on xfce. The terminal is visible on the top right corner so as to show that nothing was run in the background.

This is how my desktop looks with xfdesktop and conky running

For take one, I killed xfdesktop and the background turned black

And after that I set the background with feh and conky got transparent with fake transparency

For take two, I did not kill xfdesktop, I just run feh the same way and it just filled conky's black background. Here with the wallpaper set to scale, so that you can see the misalignment on the corner, because xfdesktop places it centered

And here with feh setting the wallpaper to centered, making a perfect fit

After all that, I think there is no doubt that conky on xfce draws its window using xorg's "root window" as a background and not xfdesktop, which practically draws the desktop and the wallpaper. There is also no doubt that it can do fake transparency without the need of a compositor.

[Caellian]

Alright, I reopened the issue. Didn't know that "copy bg content hack" was implemented which changes things. Sorry for being so stubborn while in the wrong, just trying to keep the issues clean.

Now I am sure that xfdesktop and conky do not play well together. Any ideas why?

Based on the video, conky does pickup xfdesktop image at first, then the xfdesktop turns black, conky follows and then after xfdesktop is shown again it conky doesn't update the second time.

Ideas:

• black background has to do with timing?
  • first update here (if own_window), second one here
    • then XFillRectangle is called if built without XDBE and use_xpmdb is true
  • fix: launch conky 1s after xfdesktop so it doesn't catch it while it's black.
• why is xfdesktop black: it's moved "to desktop" during init or monitor property changes?

[pitsi]

I can only answer one question, the one about when conky launches. On login, xfdesktop is started with the entire xfce session that also launches e.g. the panel and the window manager.

After that, the following are started and in that order: a script that gets bing's wallpaper of the day, conky, hplip on the tray, wbar, xfce notification daemon and xfce settings daemon. From those, only the wallpaper script and conky is what I have manually added to the session's startup.
I thought the wallpaper script would cause the issue, but disabling it and setting the desktop to a solid color, e.g. beige, makes the background beige and conky remains black.
Unlike openbox, where everything that starts is listed inside ~/.config/openbox/autostart and the user can change order and insert some delay times times with sleep, here they start alphabetically and no delays can be added.

[Caellian]

You can add delay by starting conky from a script with sleep:

(sleep 10 && conky ARGS) &  

[pitsi]

Does it help to say that I disabled conky from the startup apps, let xfce boot to the desktop, run it manually once everything was loaded and it does the same?