polybar: [Bug]: version 3.7.0 is has a pixelation bug

Checklist

I have read the appropriate section in the contributing guidelines
I believe this issue is a problem with polybar itself and not a misconfiguration on my part
I have searched for other open and closed issues that may have already reported this problem
I have checked the known issues page for this problem.
I have followed the debugging guide to narrow down the problem to a minimal config.

Steps to reproduce

I simply launched my standard polybar after upgrading from 3.6.3 -> 3.7.0 and it became surrounded with colourful pixels like this:

Note, that I’m running Arch Linux with i3 on an asus laptop with an intel video card through a Dell WD19TB dock connected to 2 external monitors. The issue wasn’t there when I disconnected the dock and only used my laptop screen.

I tried downgrading polybar back to 3.6.3 and the issue was immediately fixed.

For anyone on arch, you can downgrade to your cached version by running something like: sudo pacman -U file:///var/cache/pacman/pkg/polybar-3.6.3-3-x86_64.pkg.tar.zst

Minimal config

I tested without any custom configuration and the issue was there.

Polybar log

No response

Expected behavior

I wasn’t expecting to see any colorful pixels.

Actual behavior

My polybars, on all 3 screens, were surrounded by colorful pixels.

Window Manager and Version

i3 version 4.23

Linux Distribution

Arch Linux

Polybar version

polybar 3.7.0

Features: +alsa +curl +i3 +mpd +network(libnl) +pulseaudio +xkeyboard

X extensions: +randr (+monitors) +composite +xkb +xrm +xcursor

Build type: Release
Compiler: /usr/bin/c++
Compiler flags: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -g -ffile-prefix-map=/build/polybar/src=/usr/src/debug/polybar -flto=auto -O3 -DNDEBUG -Wall -Wextra -Wpedantic -Wdeprecated-copy-dtor -Wsuggest-override
Linker flags: -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -flto=auto -Wall -Wextra -Wpedantic -Wdeprecated-copy-dtor -Wsuggest-override  -Wall -Wextra -Wpedantic -Wdeprecated-copy-dtor -Wsuggest-override

Additional Context / Screenshots

I should also note that I repeated this test on 2 different laptops and 2 different Thunderbolt docking stations, and the bug persisted in all cases.

About this issue

Original URL
State: open
Created 8 months ago
Comments: 27 (12 by maintainers)

Commits related to this issue

fix(render): Deal with incomplete wallpapers If the root pixmap does not fully cover the bar window, some pseudo-transparent areas were filled with unitialized data, causing pixelation or other rende... — committed to patrick96/polybar by patrick96 4 months ago

Most upvoted comments

Alright, now we’re getting somewhere, I can finally reproduce on my own!

Steps:

Turn off second monitor
Set wallpaper feh --no-fehbg --bg-fill /path/to/image.
Turn on second monitor and configure it to the right of the first one (below should also work)
Run polybar on second monitor

Because in the second step, the wallpaper was set when only the first monitor was connected, the area defined for the wallpaper is only the area of the first monitor. When connecting the second monitor, the wallpaper image is simply tiled in all direction (I believe this is the expected behavior when the underlying image is smaller than the space it is intended to fill).

we never overwrite the contents of the buffer we use to store the wallpaper, so it just contains whatever random data was there in memory before; interpreted as colors those are various colored pixels.

This is indeed what’s happening.

The correct behavior here should be that polybar prints an error message if this happens and displays as much of the wallpaper as possible while filling the rest with black.

@mikeboiko Thanks again for helping me debug this.

I think you have something somewhere that does set some kind of wallpaper, not sure what though. And when you then connect the external monitor, there is no wallpaper defined for that monitor and polybar basically renders garbage

patrick96 on Feb 18, 2024

Thanks a lot, your experiments have the expected results, it is indeed the pseudo-transparency (and only the pseudo-transparency) that causes this. Finding the issue in the code will likely take some time, I’ll let you know once I have something for you to test out.

BTW, my original border-color was set to #00000000. I guess it should be a 6 digit hex value instead of an 8 digit hex value.

This is on purpose. This is a fully transparent color (format AARRGGBB) to make it look like the bar is not flush with the edge of the screen (even though the window actually is and just has a transparent border).

Not 100% sure what this setting does, but it’s a good enough patch for now!

Pseudo-transparency simulates transparency without needing a compositor. It takes your wallpaper and puts the bar on top of it. The transparent parts of the bar will show the wallpaper below, making it look like it’s transparent.

patrick96 on Dec 5, 2023

That would be great, thanks! Let me know if you run into issues. Getting older versions to compile can be a pain

patrick96 on Dec 4, 2023