search

dev-andi / xfce-blur-effects

Creates Window Blur effects on XFCE
GNU General Public License v3.0
23 stars 6 forks source link

Effective realtime blur #3

Open nick87720z opened 1 year ago

nick87720z commented 1 year ago

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).

nick87720z commented 1 year ago

There's issue discussian about kawase blur reinstatement: https://github.com/yshui/picom/issues/32 Although I looked screenshots for this project - looks good, at least less dull than total opaqueness.

Btw, specially about software implementation - even doing in SIMD (I would just use gcc vector ext), it's easy to hit data transfer speed bootleneck if doing in naive way. I tried to implement these filters in GNU Awk for own camera backlight daemon, using persistently runing ffmpeg, converting frames to 1x1 greyscale raw, with hexdump converting to readable text for awk, and awk finally interpresint this - there I tried to make smooth reaction, trying to us kawase blur approach to smooth in time. Rather than write result of each stage to texture, must be more effective to have box-sized buffers between them, so that accumulative box implementations could be concatenated and be more effective.