Long-running custom shaders

Currently you can set a custom shader for short animations (window open, close, resize) but not for something long-running. For example, you can't put a custom shader on a window or an output in general. This can be used for fun effects, but also for things like grayscale mode, or desaturating unfocused windows and such. The reason I haven't added it yet is that it requires some damage tracking design. While short animations can sidestep the problem and always draw with full damage, anything long-running should report correct damage whenever possible since this massively affects power consumption and background system load. I have two ideas on how to handle this. One is to have a property that you must set when using a custom shader that tells niri how it affects damage. The two obvious values are: does not affect damage (i.e. the shader changes each pixel independently), requires full damage (the shader can do whatever it wants, but same input texture always produces the same output texture), and requires full damage and is animated (the shader can do whatever it wants and accepts current time as input for animations). Second idea is to also offer different shader interfaces for these values. Like, for shaders that do not affect damage, offer a `vec4 process(vec4 color)` interface that processes each pixel individually. I suspect this could be unnecessarily limiting, and well, if you're writing a custom shader and set the damage property wrong, then the worst thing that

Posted by YaLTeR on Jan 1, 2025, 7:53 PM

Tags

• github (Other)

Related issues

• struct's lifetime requirements can be bypassed via covariant field assignment
• Proposal to Reorganize the Moderation Team and Review Moderation Policies
• Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
• proposal: container/...: generic collection types
• Better Custom Endpoint BYOK
• A concrete policy for backward compatibility until Godot 5.0