Artifacts when wallpaper is not set

[musjj]

Output of `awesome --version`:

awesome 4.3 (Too long)
 • Compiled against Lua 5.1.4 (running with LuaJIT 2.1.0-beta3)
 • API level: 4
 • D-Bus support: yes
 • xcb-errors support: no
 • execinfo support: yes
 • xcb-randr version: 1.6
 • LGI version: module 'lgi.version' not found:
	no field package.preload['lgi.version']
	no file './share/lua/5.1/lgi/version.lua'
	no file './lgi/version.lua'
	no file './lgi/version/init.lua'
	no file './lib/lua/5.1/lgi/version.so'
	no file './lgi/version.so'
	no file './lib/lua/5.1/loadall.so'
	no file './lib/lua/5.1/lgi.so'
	no file './lgi.so'
	no file './lib/lua/5.1/loadall.so'
 • Transparency enabled: yes
 • Custom search paths: yes

How to reproduce the issue:

1. Set useless_gaps to any value above 0
2. Set your layout to tile
3. Spawn multiple windows in your first tag and a single window on any other tags
4. Set a wallpaper outside of your awesomewm config (e.g. feh --bg-fill bg.jpg)
5. Make sure your config doesn't contain any wallpaper configuration
6. awesome.restart()

Actual result:

A screenshot of two tags, before reloading awesomewm:

A screenshot of the first tag, after reloading awesomewm:

As you can see, the window from the other tag (the one displaying man page inside a terminal) becomes visible through the gaps. The artifact persists even when you switch to another tag:

The artifact disappears once you focus on the tag where the artifact originates from (in this case the terminal with the man page).

Expected result:

No artifacting occurs

[musjj]

It looks like that this is caused by picom. I didn't experience this on bspwm, strangely.

[actionless]

does this also happens when running awesome with --no-argb flag?

[musjj]

--no-argb doesn't help, unfortunately. I wonder if there's a way to grab the current wallpaper and re-render that instead?

[actionless]

i'm setting wallpaper either using nitrogen or awesome itself, and it works with picom or without

since you're able to reproduce it only with picom - i'll consider it to be some compositing issue, which awesome have no power on - try reporting it to picom

[actionless]

if you really want not buggy compositing - consider finding some wayland contraption - on X it's really either slow or buggy, i myself use awesome in no-argb mode and without compositing, it's robust and fast

[actionless]

also, if you're not gaming or using CUDA/NVENC - try swapping nouveau and nvidia driver, for just desktop activity nouveau sometimes better (same for radeon/amdgpu)

[musjj]

@actionless

To clarify and summarize, the artifact only appears under the following 3 conditions:

• There is zero wallpaper configuration code in your rc.lua
• picom is active
• awesome.restart() is called

Just curious, but are you sure that you were unable to reproduce it?

[actionless]

no

that's behavior if happens very specific to particular combination of gpu and driver, as i mentioned above

[actionless]

or if not driver-specific, then most likely picom thinks that area behind useless gaps belongs to a window, so it's not updating it, letting application to do so

[sigprof]

This issue looks like yshui/picom#1081 — I can reproduce it after using feh --bg-fill something.png (as suggested here), but also after hsetroot -solid '#00004e', or even when having gears.wallpaper.set("#00004e") in rc.lua. Also the corruption disappears if I run picom with the --no-use-damage option (but that option is documented to degrade the performance).

So this is probably not an Awesome bug, but some problem in picom which is triggered by the WM restart.

[actionless]

but some problem in picom which is triggered by the WM restart.

when root background is a pixmap with RetainTemporary

i think for your situation might be enough just adding your feh command to the awesome's autostart

[sigprof]

i think for your situation might be enough just adding your feh command to the awesome's autostart

Yes, actually this works for my use case (solid color background without creating a screen-sized pixmap):

awesome.connect_signal("startup", function()
    if beautiful.wallpaper_solid_color then
        gears.wallpaper.set(beautiful.wallpaper_solid_color)
    end
end)

But setting the wallpaper that way only in the request::wallpaper handler triggers the picom bug:

screen.connect_signal("request::wallpaper", function(s)
    if beautiful.wallpaper_solid_color then
        gears.wallpaper.set(beautiful.wallpaper_solid_color)
        return
    end
    -- ... default awful.wallpaper code ...
end)

Using just request::wallpaper, but additionally wrapping the gears.wallpaper.set call in a gears.timer.delayed_call (similar to what awful.wallpaper ends up doing for its update handling) works too.

(Also apparently the current theme API does not provide a way to make a theme with a solid color background that would work on all screen aspect ratios, because the rc.lua code using awful.wallpaper accepts only an image in beautiful.wallpaper without any way to set the scaling options from the theme; but that's a completely different problem…)