anemeth added inline comments.
Restricted Application edited projects, added Plasma; removed KWin.

INLINE COMMENTS

> fredrik wrote in blur.cpp:145
> Why is this needed?
> 
> I'm probably missing something here, but it looks to me as if the effect 
> copies the contents of the framebuffer to the helper texture, then copies the 
> contents of that texture to m_renderTextures[0], after which the contents of 
> helper texture is not used again. Can't copyScreenSampleTexture() copy 
> directly from the framebuffer to m_renderTextures[0]?

This texture is only used by `copyScreenSampleTexture()`
It could very well be a separate variable, but I just appended another texture 
to the textures vector and used that instead.
The reason for first rendering into m_renderTextures.last() and then copying 
that to m_renderTextures[0] is to eliminate what I call "extended blur".
Extended blur is when windows or other elements that are not under the blurred 
area affect the blur effect. This sounds great in theory, and this is how the 
old blur method worked as well, but it becomes a big issue when the blur radius 
gets big. For example when you maximize a white window, the completely 
transparent taskbar also becomes almost completely white because of this 
effect, so the way I achieve this is by creating a GL_CLAMP_TO_EDGE effect.
F5656755: c3_clamping.png <https://phabricator.kde.org/F5656755>
For example if we want to blur a window (red) we have to blur a bigger area. To 
avoid extended blur I use the copySample shader to create a GL_CLAMP_TO_EDGE 
effect (blue) when copying the texture from m_renderTextures.last() to 
m_renderTextures[0]

Ideally we could specify to only disable extended blur on the taskbar, but I 
don't see a way to identify a window as the taskbar.

REPOSITORY
  R108 KWin

REVISION DETAIL
  https://phabricator.kde.org/D9848

To: anemeth, #plasma, #kwin
Cc: luebking, broulik, romangg, zzag, anthonyfieroni, mart, davidedmundson, 
fredrik, ngraham, plasma-devel, kwin, #kwin, ZrenBot, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol

Reply via email to