-
Notifications
You must be signed in to change notification settings - Fork 6
Description
I noticed, that this project tries to use gaussian blur. This way is known to be slow, at least for software - even with separation to per-axis stages. For comparison - picom already has kawase blur, which originally existed in xcompmgr or compton via xrender long time ago, but now reimplemented in GLSL. They also mentioned some other projects (kwin) also using such way.
First, regardless of whether you use software or GLSL, about common principle:
kawase blur is 3x box blur, which is known to achieve same result. There's better description of result from me: 1st box makes a constant (box, according to name), 2nd turns box to 2x wider linear tamp and 3d, as I guess, turns linear ramp into quadratic (I guess, each new box raises digree by 1). Thus 3 boxes are enough for smooth blur (of course, you could add 4th or just make configurable steps number - I guess, some people could be happy even with 2 of them). Of course, boxes are better have odd size, and combined size could be expressed as size + (size-1)*(n-1) for n box stages (1 pixel in following stages is included to previous stage completely rather than by half, on each side).
Feature of boxes approach, is that performance depends only on stages number, while completely independent of filter size. Combine with separate per-axis approach and I guess, even software implementation should be enough usable (I'm just not sure yet, how to make as effective GLSL implementation, as I'm too new too new to GLSL).