Modular Feature-Set (Plugins) & Better Configurability

[yyny]

The current method used by compton/picom is to hard-code certain important features and read their settings directly from the config file. Other features (Such as Kawase blur) can then be patched in. However, I've found that almost all features a compositor can provide can actually be reasonably rewritten in shader languages:

• Transparency (color.w *= opacity)
• Fading (color.w *= opacity * time)
• Blur (color = blur(sampler, color, kernel))
• Shadows (color = vec4(0) * (1 / windowDistance))
• Invert Color (color = 1 - color)
• Other custom, hand-written shaders (e.g. --glx-fshader-win)

IMHO, from a minimalist UNIX philosophy, picom should be able to ship with exactly the features a user needs, and nothing more. For a compositor that means implementing the XComposite extension and being able to render windows to intermediate buffers.

It would be really nice if all above features were rewritten completely into glsl, such that you could simply give a list of shaders to run for every window selector. Of course, this isn't entirely reasonable since there is almost certainly demand for non-GL backends aswell, and regardless, some shaders are more complicated than others, but I think it's reasonable to switch to "modules" or "plugins" that are small source files or shared libraries. They could register a callback for certain events ("Window settings changed", "Screen refresh") and obtain a reference to a texture/frame buffer/whatever the backend can provide. This is strictly more powerful than the current approach, and seems more maintainable as well. Maybe the selector filtering/dbus interfaces could themselves be implemented as plugins, although perhaps that might be pushing it. Another advantage to this is that users that do not care about certain features or back-end support can simply remove them without anyone (either end user or maintainer) having to comment out/#ifdef large sections of code scattered all across the source tree. Also, lots of existing feature requests could easily be implemented.

One problem is that modules would mess with the current config/command line flag parser (how would new plugins name their options? with a prefix?) but IMO those have never been the prettiest parts of compton anyway, and might be in need of a restructuring. The old options can still be supported for compatability, of course, but for example I don't really like how compton with kawase uses certain --blur options, but not others, or how there seems to be an -exclude = [] for every single feature. I would much prefer something like

plugins = [ "blur", "filter", "my-dither" ] # I don't use "fade" or "shadow" plugins ;)

[blur] # blur settings for any blur method
fixed-strength = true # dont scale strength with opacity
method = kawase # use kawase blur by default
[blur.kawase] # blur settings only for kawase blur
strength = 4
[blur.convolution] # blur settings only for convolution blur
kernel = [ ... ]

[my-dither]
enable = false # disable by default

# filter settings/settings for filter plugin
[filter.notifications] # define a filter to change settings for notifications
selector = "name = 'Notification'"
blur.method = convolution # use different blur method for notifications
blur.kernel = [ ... ] # and a special kernel, because why not
[filter.noblur] # filter out window types that should not be blurred at all
selectors = [ "window_type = 'desktop'", "window_type = 'dock'" ]
blur.enable = false # don't blur desktop
[filter.dosbox] # custom dosbox shading
selectors = "name = 'DosBox'"
my-dither.enable = true

to keep the config file readable and organized, especially for people like me with auto-generated config with large lines of blur kernels and lots of exclude filters.

I might look into implementing this myself, once I understand the picom code and if there is demand for it (and I have to say, picom is already much more readable than the original compton 👍)

Thoughts?

[clort81]

per-window glsl shaders would be good.

[yyny]

Another problem I am finding is that in the current code path, modules should be loaded after logging is initializer, but also before config/cli-arguments have been read. This means we can't log module initialization failure unless we use WARN log-level or higher, or if we 'preprocess' the entire argument list/config file to look for --loglevel which are both silly. Obvious solution is to parse options and "remember" options intended for currently unloaded modules so we can apply them when they are loaded.

Actually, I like the idea of allowing the modules themselves to add hooks to read the argument list or config file if they want to, so we can write the entire compton compatability layer in a module too.

Syntax for module arguments should probably look like picom --option blur.method='kawase' or even picom --option blur[method='kawase',fixed-strength=true]

[yyny]

UPDATE
What I got so far
I currently only implemented dbus as a module, to provide an example.
The other modules take significantly more work, since their implementation is scattered throughout the source tree.
I almost implemented the blur module locally, but it's still incomplete.

Additionally, there are still several design problems currently, including the one mentioned above.

[yshui]

This is quite interesting.

From my understanding I think there will be at least two kinds of modules: those related to rendering and those that do not.

Because of how the backends are currently architected, making the rendering/effects extensible is quite difficult. The system is (somewhat intentionally) not designed to allow the backend rendering to change the geometry or shape of a window.

OTOH non-rendering related modules are totally doable. But the only real usecase I can currently think of is dbus. I am not sure how beneficial it will be to make dbus into a module. And we also have to be really careful what we expose as an API to the modules, which could be a lot of work.

[Demonstrandum]

I see you have a my-dither plugin in your example there. Using the Kawase blur, on darker backgrounds, with an already dark terminal creates a lot of very obvious colour-banding, which could be mitigated with dithering (I think this is what KDE does with its blur).

Is there a way I could implement a dithering shader for the background after its been blurred, now? The --glx-fshader-win applies to the whole window contents, right? It would be cool to only apply the shader to the background/what's behind the window.