Request: upgrade picom to v/12.5-1

[ceeslans]

Respectfully request to backport picom v/12.5-1 (currently offered in trixie) for MX23 testing repository.

debian trixie : https://packages.debian.org/trixie/picom
picom homepage : https://github.com/yshui/picom

[Jerry3904]

I'll be interested in testing that, thanks.

[siamhie]

I asked for that version back in November 2024 with no response. viewtopic.php?t=82768

[Jerry3904]

You're a victim, no question about it.

[siamhie]

I was going to suggest fluxbox adopt picom over compton because compton hasn't been updated in 9 years.
The version of picom currently in the repo is 9.1 and that at least came out 3 years ago but a lot has been fixed
since then with a lot of cool features added.

I did download the source for picom 12.5 back in Nov and only had to install 3 dev libraries for it to build. It sure
has more features than compton offers. The only thing I couldn't find was a nice GUI companion to make customizing
it easier like the compton-conf program.

[Nokkaelaein]

I was going to suggest fluxbox adopt picom over compton because compton hasn't been updated in 9 years.

I'm currently using Picom as the go-to compositor in the custom MX system I'm running on several computers. Built it from the most recent sources available on github, and use it with Fluxbox. Thinking along the same lines, a while ago I was also going to suggest (or at least hint at) potentially making Picom the default compositor in the Fluxbx version of MX, but the current version needed some hackish solutions on my part to make it work seamlessly [edit: at least on the systems I have it running, all of those have integrated graphics], so I decided not to suggest it for now. Namely, it doesn't play nice with Virtualbox when running it in a guest, and I needed to write a script for launching it that checks the running system's virtualization status, and when running on actual metal it launches using the glx backend, when running on the oracle VM architecture it launches using the xrender backend. It also still left glitchy trails on screen in some situations in Fluxbox without turning off the damage monitoring ("damage" in this case meaning the parts of the screen that need to be redrawn, not any actual damage), stuff like that. Still, having now used it for a good while, keeping these tweaks/hacks in mind, it has been a very solid compositor and I quite like it - but at the moment it didn't seem like a problem-free general choice for a Fluxbox distro that should work out of the box in as many use cases as possible.

[siamhie]

@Nokkaelaein Which backend is your config using? The default is xrender but I've switched to glx.

Code: Select all

# Specify the backend to use: `xrender`, `glx`, or `xr_glx_hybrid`.
# `xrender` is the default one.
#
backend = "glx"
#backend = "xrender";

[Nokkaelaein]

@Nokkaelaein Which backend is your config using? The default is xrender but I've switched to glx.

Yeah, glx most of the time for me as well.

Usually I'm passing it directly as a command line parameter, based on whether it's running inside a VM or not. So on this laptop I'm currently writing this with, picom has been launched with something like:

Code: Select all

picom -bcf --backend glx -D 20 -O 0.25 -I 0.25 -l -13 -t -13 -r 15 -o 0.8 --blur-method none --vsync --no-use-damage --no-fading-destroyed-argb --shadow-exclude 'class_g = "conky"'

[Jerry3904]

I was going to suggest fluxbox adopt picom over compton because compton hasn't been updated in 9 years.

I'm currently using Picom as the go-to compositor in the custom MX system I'm running on several computers. Built it from the most recent sources available on github, and use it with Fluxbox. Thinking along the same lines, a while ago I was also going to suggest (or at least hint at) potentially making Picom the default compositor in the Fluxbx version of MX, but the current version needed some hackish solutions on my part to make it work seamlessly [edit: at least on the systems I have it running, all of those have integrated graphics], so I decided not to suggest it for now. Namely, it doesn't play nice with Virtualbox when running it in a guest, and I needed to write a script for launching it that checks the running system's virtualization status, and when running on actual metal it launches using the glx backend, when running on the oracle VM architecture it launches using the xrender backend. It also still left glitchy trails on screen in some situations in Fluxbox without turning off the damage monitoring ("damage" in this case meaning the parts of the screen that need to be redrawn, not any actual damage), stuff like that. Still, having now used it for a good while, keeping these tweaks/hacks in mind, it has been a very solid compositor and I quite like it - but at the moment it didn't seem like a problem-free general choice for a Fluxbox distro that should work out of the box in as many use cases as possible.

Thanks for the detailed report.

[ceeslans]

-- snip --
... but the current version needed some hackish solutions on my part to make it work seamlessly [edit: at least on the systems I have it running, all of those have integrated graphics] -- snip --

When speaking of glitches/hacks with picom's current version, are you referring to v/9.1 (bookworm) - or latest build v/12.5 ?