Question about removal of XShape

[adiosocelote]

The original project uses XShape, but it was completely removed, from what I've noticed, from your fork. What is the reason for that?

Also, I'm using your fork and I noticed that, upon restarting your window manager, some windows like Brave need fastcompmgr to be restarted as they don't render properly anymore (works fine after a restart of fastcompmgr), which I assume has something to do with the removal of XShape. Though this is a niche bug/issue, because it only happens when I restart dwm or other Window Manager. That does not happen with Picom or original Xcompmgr, btw, but you don't really restart your window managers in general, so that does not matter, truly.

Needless to say, your fork is now my go-to compositor, because it's fast and simply (and I actually fork it and strip everything that is not transparency, but the pseudo-issue described above is from your version, cloned and built). Cheers!

[tycho-kirchner]

Hi, and thanks for the report.

The original project uses XShape, but it was completely removed, from what I've noticed, from your fork. What is the reason for that?

It was not completely removed, but never added 😉, Note that I forked an early version of compton from 2011 and apparently this feature was merged into xcompmgr shortly after the compton fork was created (see here). I guess it can quite easily be cherry-picked into fastcompmgr. Indeed, as described in the corresponding bug report, xeyes does not render properly in fastcompmgr.

Also, I'm using your fork and I noticed that, upon restarting your window manager, some windows like Brave need fastcompmgr to be restarted as they don't render properly anymore

Well, I just installed Brave v1.67.123 (on Debian Bullseye) and neither with dwm nor with fluxbox or openbox I see any issue. Can you describe (or video-record) more specifically what happens? Does fastcompmgr print any erros? Also, as it is good practice in general when reporting bugs, what are your specs (fastcompmger version, Distro, Display-manager, graphics card, driver (i.e. inxi -G), etc?

[adiosocelote]

Did not know about that tiny detail. I am not a long time Linux user, so I was not aware of that it was added later(started using Linux in 2020 or 2021, so I'm still a baby :P). I couldn't really find any information about XShape, so I figured "you removed it" (which is not the case), because it was causing some bugs or something.

---

This is what I'm talking about: https://github.com/tycho-kirchner/fastcompmgr/assets/151365544/966f7c7d-e30f-430e-bad2-86b8dae6c59e

There's that one moment where my wallpaper changes, this is when I press the restart button for my dwm.

inxi -G:

  Device-1: AMD Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT]
    driver: amdgpu v: kernel
  Display: x11 server: X.Org v: 21.1.13 with: Xwayland v: 24.1.0 driver: X:
    loaded: amdgpu unloaded: modesetting,radeon,vesa dri: radeonsi gpu: amdgpu
    resolution: 1: 1600x900~60Hz 2: 1920x1080~72Hz
  API: EGL v: 1.5 drivers: radeonsi,swrast platforms: x11,surfaceless,device
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 24.1.3-arch1.1
    renderer: AMD Radeon RX 6700 XT (radeonsi navi22 LLVM 18.1.8 DRM 3.54
    6.6.37-1-lts)```

No fastcompmgr version as the video shows I'm cloning your repo, building and launching it. :)
Hope the video is of good enough quality to see that.

Though, again, this issue doesn't really matter. It only happens upon restarting your window manager, so not really an issue as you rarely do this.

[tycho-kirchner]

Thanks. This bug is most likely related to the yet unhandeled _GTK_FRAME_EXTENTS already mentioned in this bug report. In a few weeks, I hope I'll have the time to implement them properly, once that is done, maybe your bug vanishes too. Btw., what exactly does your "retart dwm" button do? Kill and relaunch or is there some builtin restart functionality (not a dwm user here)?

[adiosocelote]

My restart button is basically:

void quit(const Arg *arg) { wm->restart = arg->i, wm->running = 0; }

Which basically makes the run loop no longer continue:

void run(void) {
  XEvent ev;
  XSync(wm->dpy, False);
  while (wm->running && !XNextEvent(wm->dpy, &ev))
    if (wm->handler[ev.type])
      wm->handler[ev.type](&ev); /* call handler */
}

And then it just end the program:

int main(int argc, char *argv[]) {
...
  run();
  cleanup();
  if (wm->restart)
    execvp(argv[0], argv);
  XCloseDisplay(wm->dpy);
  free(wm);
  return EXIT_SUCCESS;
}

My (bad) code can be viewed here.

[tycho-kirchner]

Thanks. In the beginning you wrote

or other Window Manager

What other window manager was this? Could you please also test, whether it happens in a non-dwm session (e.g. xfce4-session) when calling

xfwm4 --replace # or
openbox --replace

If it doesn't happen there, please additionally test, if it happens after

openbox --exit
openbox

Finally, what Linux-Distribution do you use? Arch?

Thanks, Tycho

[adiosocelote]

I actually tried with AwesomeWM as the other WM (not sure why I said "other Window Manager", probably another brain fatal error :P). I don't use any Desktop Environments like xfce, so can't really test. I only ever used Cinnamon (back on Mint, when I switched to Linux), Awesome and dwm. Aside of that, I would have no idea how to soft-restart xfce.

Also, not sure if I mentioned it, but the original xcompmgr (from the link in first post), and Picom (and git-cloned version) does not have this issue. And because xcompmgr is almost the same code as fastcompmgr, I assumed it's the XShape that does that, as the window you see in the video is not a square, but it has rounded corners etc (I mean, it's still a cubic window, but it's supposed to have rounded corners, which is does with other compositors, and fastcompmgr if I don't soft-restart). So I believe it'd be fair to implement XShape and see if it still happens, but I'm not here to tell you what to do - you do you.

---

I'm on Arco Linux (Arch Linux based). Always up-to-date, so if you want to know a version of a package I'm using, it's always fair to see what is the latest update for Arch and I have it, as I update every day, because otherwise I forget to update for months.

[adiosocelote]

Just found out the reason for fastcompmgr to break the rendering upon restarting the WM. It's not tied to WM restart. It happens when you try to re-launch it. Simply have fastcompmgr running in the background (setsid -f fastcompmgr) and launch it again without closing the previous one - the compositor will break.

Steps to reproduce: have fastcompmgr running, in any way, then launch it again, in any way. For example

setsid -f fastcompmgr; sleep 5; fastcompmgr

(sleep not required).

I have no idea what could cause that, though. I tried moving register_cm(scr) right after XOpenDisplay, but that did nothing. But at least I tried something. :P

[tycho-kirchner]

Nice finding! Never was hit by that bug, because either I killed the existing compositing manager before firing up fastcompmgr, or, if it failed, I killed the other one and then immediately tried it again. Anyways, I'm confident that this bug is now fixed by 33ea2f832028c15d3d0dfb519026e3beec161f76.