When my blur radius is set to merely 10, my GPU usage doubles every time I open a GUI that's blurred.
A great addition would be a more efficient blur algorithm (or even several), something like StreamFX for OBS has. The examples linked have relatively detailed info on how they work, and I barely see any performance decrease while using these filters.

I currently lack the required knowledge about OpenGL and Shaders to do that.

On 1.20.2 this mod still causes a massive FPS drop, even when not in menus.

I have done a proof-of-concept implementation of Dual Kawase Blur(at vgskye/Blur), which seems to give good results and should be faster, but it has completely different config options from Gaussian and fade-in/-out is somewhat worse because dual kawase can't smoothly fade from zero blur to blur(well, as far as I know). the code is also kinda a mess with multiple low-hanging fruits for optimization and bad variable names in shaders, but it might be helpful

Has anyone done testing on how performant the blur fx mojang added in the new snapshots is? Perhaps we could just backport that if we can't get fading for Dual Kawase Blur

On lower end machines this is detrimental to FPS
Test methodology: open inventory screen, wait 10 seconds for good average, get result
This was all done on a Intel i5-8265U @1.60GHz running on integrated graphics, 8GB ram

Blur radius 0: avg 53fps

Blur radius 8: avg 41fps

Blur radius 16: avg 24fps

Blur radius 32: avg 14fps

@Motschen any news on improving performance?

I also noticed this issue and literally made a GitHub account specifically to post lol

I really love this mod in general so I hope it gets fixed soon, and maybe some additional info can help

I've also been experiencing MASSIVE frame drops due to this mod, but this time not while a menu was active. For whatever reason, it was just constantly crushing my frames and taking ~65% of my processing time. I have a pretty decent computer so I dropped to ~30fps instead of being crushed to 10fps, but I get ~140fps normally so its a huge difference.

Computer specs:
CPU: i9-11900H 2.5GHz (has integrated GPU but not using it in this case)
GPU: RTX 3080 Laptop
32GB RAM

Mc info:
1.18.2 Fabric 0.14.10
Sodium, Phosphor, FerriteCore, Lithium, Indium (Yes I know there are redundancies)
Java 17.0.1

Anyways, I ran a Spark profiler and looked at the results since I was super confused why my FPS was so low and found that the org.lwjgl.opengl.GL11.glCopyTexSubImage2D() thread was taking up a MASSIVE amount of my processing time, over 65%

I couldn't for the life of me figure out which mod it came from, so I disabled most of my cosmetic mods and slowly re-enabled them in small batches. Once I re-enabled Blur and another mod, I found the fps drop again lol. After removing, the thread completely disappeared so that seems to confirm that this was my issue at least.

I tried looking around in the src but couldn't find any functions related to the glCopyTexSubImage2D() thread that was killing my frames, but obviously I'm not the author and I'm also new to coding especially in Java so I'm VERY likely to miss it.

Hopefully this info can at least help somewhat with this issue, again I really love this mod its just a shame the fps drop is so insane

I was a bit curious too, so I found time to work on this issue, and I leave this as I created a commit.

lonefelidae16@4f515a4

I knew the following part of shader file was the bottleneck because FPS drops significantly when radius is increased:

So to solve this, the next step is to reduce the number of iterations of this loop. But I’m not good at GLSL shaders, I apologize if I’m misguided.

I’ll decide to adopt Gaussian Filter. As mentioned by stashymane, the implementation of StreamFX was very helpful. However, we’re modding on Minecraft, so there are LWJGL’s limitations.
Having as many as 127 kernel sizes like StreamFX hasn’t yet been achieved. And this will improve FPS, but the area affected by the effect will be extremely limited. It’ll be a shame for some.

Current implementation:

Gaussian filter with 31 kernel sizes:

The current implementation is good, so I think optimizing and resolving this issue may lead to a reduction in appearance. It’s a trade-off, so perhaps it’s inevitable. I’d be happy if anyone else can come up with a better implementation.

Gaussian filter with 31 kernel sizes:

That looks fantastic. If you have a built jar for 1.20.x could you please send it to [email protected]

That looks fantastic. If you have a built jar for 1.20.x could you please send it to [email protected]

Uploaded to my repo, please check.

lonefelidae16@09ab30c#commitcomment-121820617