Full Screen Post Shader?

[MixusMinimax]

From what I've seen, I don't think it's possible, but I always wanted to be able to run a glsl shader over the entire screen, after everything has been rendered to the buffer. There are soooo many things you could do, like:

• Color adjustments
• Transformations like flipping, screen magnifier, rotating, etc
• Special effects like scan lines or screen distortion or chromatic abberation or bloom (I would like to make the entire screen look line a crt monitor for example, and not just windows on their own, I know about cool-retro-term ;))

Is that something Xorg even allows? I have not been able to find anything about this, other than very surface level stuff.
I was thinking something along the lines of copying the screen backbuffer into the buffer of a borderless fullscreen window that is click-through, and applying a shader there. Maybe picom is not the solution for this, but maybe somebody has some ideas or experience with this.

If this is too far off-topic, I'm sorry for being annoying :D

[RobertZenz]

Is that something Xorg even allows?

I can only speak as a user, but absolutely as far as I'm aware. Compiz is another compositor that offers exactly this functionality. If I'm understanding the X11 architecture right, pretty much everything is handed over to the compositor for, well, composition, and that also allows manipulation on a large scale like through a shader. The compositor has tot support it.

There is the compton-default-fshader-win.glsl file which should contain the default shader that is being used, editing that one would lead to different "global" shader being applied. So what might be missing would be support to plug in a different one at runtime.

[MixusMinimax]

Thanks, I'll look into it!

[tryone144]

I was thinking something along the lines of copying the screen backbuffer into the buffer of a borderless fullscreen window that is click-through, and applying a shader there.

This is essentially what picom already does (at least in the new backend). Adding a custom shader stage when drawing the screen to #507 should not be too hard.

Having said that, a screen magnifier would require tracking of mouse events and dynamically toggling that shader which might be a bit out of scope for picom.

[MixusMinimax]

Okay thanks! The screen magnifier thing might not be that bad, tbh I've just always dreamt of having my screen look like an old crt, and as long as that's possible, I'm happy.

[kosshi-net]

I want this feature so bad for desktop color management. If we could just write a shader to run on post fullscreen, and preferrably in different passes per screen, that would allow us to solve many shortcomings the Linux Desktop has with color accuracy.
I'm currently using a custom window shader to do gamut clamping for my wide gamut monitor, it works but has some issues. Since there's no way to discriminate between what display the fragment is in, only one of my monitors can be color-accurate. Also, the window shader is not applied to my wallpaper for whatever reason.

I can totally look into implementing fullscreen post shaders myself, but I'm not sure how to do it in a general-purpose way. Color management is really complicated and clearly out of scope for picom, same story for other things like zoom discussed in this thread.
An optimal solution would be some sort of plugin system, so you can feed your shaders with whatever uniforms you wish. But is this either in scope for picom, and how would something like this even be implemented optimally?

I'm seriously considering writing my own compositor now ...

[nick87720z]

Also, the window shader is not applied to my wallpaper for whatever reason.

May depend on desktop program. At least with xfdesktop it works. Could it be, that it has no own window, but just renders to root?
I checked own with shader below by just commenting out line, fetching one pixel (central) for convolution, which maks it to appear like garbage (uninitialized color value is still used).

[nick87720z]

I made shader for fullscreen subpixel antialiasing.
This would be really best as screen post-proc and with support for multiple shaders.
For now - only window one pass mode works, with worse performance and slightly worse result (window edges look not so good).

It's in the wiki: https://github.com/yshui/picom/wiki/Shader-Shop#fullscreen-subpixel-antialiasing

In short - it does all the filtering as antialiasing usually does, while Xrandr just picks ready to use pixels while downscaling in nearest neighbor mode.

There are parameters, set with #define directive:

• wx_3fold - set to 1 to discard pixels, ignored by xrandr nearest filtering.
• FUNC chooses function.
  • 0 - default. Greyscale 3x3 box (just as reference FSAA, only in non-standard size). Good for initial test if everything works.
  • 1 - linear RGB filter (layouts, supported by config).
• STAGE - stage to run. For now only subpixel filter has additional stage for compensating sharpening, used to preserve contrast after 3x box filter.
• For FUNC == 1:
  • pair of defines to choose RGB direction (RGB or BGR)
  • same, but for orientation
  • Perceived subpixel shift in pixel size fraction. Some LCD displays try to make it look reduced.
  • Softness factor, used for resharpening. Being precisely - it's about how many times neighbor neighbors value is subdivided before to leak into central pixel. For now recomended value - 12. Lowers value make contrast more exaggerated (up to clear embossement), while lower - more blurry. It's tuned to at least restore sharpness for freetype fonts (though other graphics should benefit too).

It uses kawase sampling technics for greyscale box part. Unfortunally it's unusable for both subpixel part (need channel shift before mix) and sharpness (fractional sampling can't lead to negations).

---

About performance.

When sharpness is done in one stage with other part - this leads to triple job due to need for 3 output pixels from previous stage.
With multiple stages - I got potential number of fetches reduced by ~2x.

Must note - it's unlikely suitable for real use with integrated graphics - I get slideshow with i5 sandybridge 3.1GHz with only 1366x768 physical screen (it's most true 4k when multiplied from 1 Mpix to 9).

[nick87720z]

I have some filling it could disappear, at least on this hosting. Please let me know if that happens. I did this celebrating expiration for patents, covering subpixel rendering.
Edit: nevermind.