User-defined shaders - Githubissues

WillPower3309 / swayfx

SwayFX: Sway, but with eye candy!

MIT License

1.17k stars 47 forks source link

User-defined shaders #110

Open CyberShadow opened 1 year ago

CyberShadow commented 1 year ago

Hi, thank you for this project.

I'm wondering if this project could have something equivalent to picom's window-shader-fg-rule, which allows specifying a user-supplied GLSL file to use for windows matching user-defined rules.

Such a feature would allow achieving e.g. the following:

Smart color inversion (for applications not supporting a "dark mode")
Color-key based transparency (for applications without native transparency support)
Ad-hoc hacks / accessibility improvements (adding guides/crosshairs, color correction for color blindness)

Upstream issue (closed WONTFIX): https://github.com/swaywm/sway/issues/3652

WillPower3309 commented 1 year ago

This should be relatively easy to implement, and I'd accept any PRs implementing this

WillPower3309 commented 1 year ago

For more context, we could implement this with an initial rendering pass that applies the user defined shader prior to our shaders

xplshn commented 1 month ago

Maybe, need to investigate how modular Vulkan shaders are, and how this would interact with a potential migration to compute shaders.

Why not use "slang"?

Arguments in favor of slang would be:

Slang is backwards-compatible with most existing HLSL code. It is possible to start taking advantage of Slang's benefits without rewriting or porting your shader codebase.
The Slang compiler can generate code for a wide variety of targets and APIs: D3D12, Vulkan, D3D11, OpenGL, CUDA, and CPU. Slang code can be broadly portable, but still take advantage of the unique features of each platform.
And lots more that aren't related to Slang's compatibility with platforms but rather the language itself