You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 can happen is you get some weird redrawing on screen.
The text was updated successfully, but these errors were encountered:
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 can happen is you get some weird redrawing on screen.The text was updated successfully, but these errors were encountered: