paperview + compositor

[plasmoduck]

Hi glouw, looking through the discussion on the non-SDL2 gist you link in the readme. I may be wrong but I'm pretty sure that if you did go down the route of using the XRender extension instead of SDL2 that this compositor issue might go away. Perhaps you could make a non-sdl2 multi monitor version of paperview using XRender instead of SDL2 and see if this works?

[pseregiet]

This program will not work with any compositor because of how compositor and this tool works. Normally in X11 you have your root window (wallpaper) and a bunch of windows on top of that. X server first draws the root window (wallpaper) and then the rest of windows that you have opened. This program renders its animated graphics directly to the root window, so without any compositor you get an animated wallpaper. When you run compositor though, X11 no longer draws the windows on the screen. Instead it sends the image of each window to the compositor. The compositor can do whatever it wants with the window (make them transparent, round corners etc.) and the final frame of your whole desktop is renderer to the root window (wallpaper) as that's the only window that X server still draws.

In effect when you run a compositor and this program at the same time it's a race condition who draws later, overwriting what the previous program did. on xcompmng for example I get flashing, sometimes I see the windows and sometimes I see the animated wallpaper

The only way to make this tool work with a compositor is to change it's implementation. Instead of drawing to to the root window you should tell X server to use another piece of graphics as the new wallpaper. Or you can modify your compositor, make it use your own graphics (animated or not) instead of the X server wallpaper.

[plasmoduck]

Instead of drawing to to the root window you should tell X server to use another piece of graphics as the new wallpaper. <- This sounds promising!

[pseregiet]

Well, I looked into this over the past few days. Unfortunately there's no way to make it work fast without doing it directly in the compositor. I can make a new pixmap, copy graphics to it every few milliseconds and submit that pixmap as the new wallpaper and it does work with or without compositor, but it is quite slow. Making the pixmap use shared memory (which should speed up things a lot) does not work. I get a black screen. In fact, all the compositors start complaining about there being an invalid window, so clearly that does not work with wallpapers. In general it seems that the wallpaper mechanism is stuck in the past and no modern extensions like shared memory work with it.

I hacked on xcompmgr (as it's the simplest compositor around) and made it to fetch the graphics for wallpaper from my bmp files instead of asking X for the real wallpaper and it works very well. Maybe it would be worth submitting to picom, but I'm thinking of some more generic solution. Displaying bmp files in sequence is cool, but I'd like a full 3D context as a wallpaper so I can display some procedural 60fps graphics. At the same time picom seems very messy, they have some experimental backends, several options for the same feature, some slow, some fast... I don't want to criticize outright, I have learned how hard and weird X11 can be, so I suspect there are valid reason for at least half of it, but I'm not sure about all of it. I'm quite determined to create my own compositor now... wish me luck btw I'm not the author of this program. I just found it accidently and got inspired

[plasmoduck]

That sounds pretty awesome man! Good luck with that! I'd be keen to use, test and contribute if you put the code up.

[plasmoduck]

pseregiet hows it going?