Is this still needed when qPow() is not used?

Okay, I see what you mean. I think this is a trade-off between two undesirable effects though, because the clamping causes abrupt changes near the edges of the blurred region when a window is moved. You can see this effect pretty clearly in the video you attached when the blur strength is set to strong. It really comes down to what you think is worse though.

But my concern here is that a fullscreen texture consumes at least 8 MB of VRAM with an HD monitor, and 32 MB with a 4K monitor.

I think it would be better to copy the framebuffer to m_renderTexture[0], and apply the clamping as a post-processing effect, using m_renderTexture[0] as both the source and destination, and targeting only the region outside the red rectangle for rendering. Using the same texture as both the source and destination is allowed in OpenGL when GL_ARB_texture_barrier or GL_NV_texture_barrier is supported, but unfortunately not in OpenGL ES.

The taskbar (and other panels) can be identified by calling EffectWindow::isDock().

It looks like that was added by Martin in 111db93e05a55496e7f13788207ead008bac80db.

The first letters in the enumerators should also be capitalized.

This assumes that s_renderTargets is empty when this function is called, which might not be the case.
How about naming it pushRenderTargets(), and have it add the targets to s_renderTargets instead of replacing it?

Now only the taskbar doesn't have the extended blur effect.

GL_ARB_texture_barrier is supported since OpenGL 4.4, but KWin uses 3.0
GL_NV_texture_barrier is supported since OpenGL 3.0 but it only works on Nvidia right?
What about AMD and Intel GPUs then?
I guess mostly the older and weaker cards would be benefit from this, but the chance is higher that they don't support this extension.
Is it worth the hassle to only implement this for Nvidia users?

I guess it's an unpopular opinion, but it's "only" 8 MB and since cards these days have at least like 1 GB of VRAM it's not a big concern.

How do you suggest we handle this?

I'm working on a nicer solution with less magical numbers.

I checked if I have these extensions. Just to make sure it works I included another extension I know my card supports.

qCDebug(KWINEFFECTS) << "NV_texture_barrier:" << hasGLExtension("NV_texture_barrier");
qCDebug(KWINEFFECTS) << "ARB_texture_barrier:" << hasGLExtension("ARB_texture_barrier");
qCDebug(KWINEFFECTS) << "GL_NV_texgen_reflection:" << hasGLExtension("GL_NV_texgen_reflection");

And the output:

kwineffects: NV_texture_barrier: false
kwineffects: ARB_texture_barrier: false
kwineffects: GL_NV_texgen_reflection: true

If this works so unreliably I don't think we should use this.

Ok I realize now that the extension name begins with GL_ and this is the reason it didn't find them.
BUT then I listed all the available extensions and since they are in alphabetical order I can easily check if texture_barrier is available.

Nitpick, but it should be <cmath> and std::ceil() in C++.

GL_ARB_texture_barrier is supported since OpenGL 4.4, but KWin uses 3.0
GL_NV_texture_barrier is supported since OpenGL 3.0 but it only works on Nvidia right?
What about AMD and Intel GPUs then?

The 3.1 backend can and does use some GL 4 extensions, but it must have a fallback path for when they are not available.

The NV prefix only tells you which vendor created the extension, not which vendors support it. The AMD drivers in Mesa have supported texture_barrier since 2011, and the i965 driver has supported it since 2015.

But as I said on IRC, don't worry about it if your driver doesn't support it. We can add a path that uses texture_barrier after this has landed.

Typo: iteratoin

Does calling effects->addRepaintFull() also work?

You could also check if s_renderTargets is empty, and just do s_renderTargets = targets when that's the case.

It does.
Changed to that.

The reserve() call should be in the else {} clause.