<table><tr><td style="">zzag created this revision.<br />zzag added a reviewer: KWin.<br />Herald added a project: KWin.<br />Herald added a subscriber: kwin.<br />zzag requested review of this revision.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D25611">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>Quite long time ago, window decorations were painted on real X11 windows.<br />
The nicest thing about that approach is that we get both contents of the<br />
client and the frame window at the same time. However, somewhere around<br />
KDE 4.2 - 4.3 times, decoration rendering architecture had been changed<br />
to what we have now.</p>

<p>I've mentioned the previous decoration rendering design because it didn't<br />
have a problem that the new design has, namely the texture bleeding issue.</p>

<p>In the name of better performance, opengl scene puts all decoration parts<br />
to an atlas. This is totally reasonable, however we must be super cautious<br />
about things such as the GL_LINEAR filter.</p>

<p>The GL_LINEAR filter may need to sample a couple of neighboring texels<br />
in order to produce the final texel value. However, since all decoration<br />
parts now live in a single texture, we have to make sure that we don't<br />
sample texels that belong to another decoration part.</p>

<p>This patch fixes the texture bleeding problem by padding each individual<br />
decoration part in the atlas. There is another solution for this problem<br />
though. We could render a window into an offscreen texture and then map<br />
that texture on the transformed window geometry. This would work well and<br />
we definitely need an offscreen rendering path in the opengl scene,<br />
however it's not feasible at the moment since we need to break the window<br />
quads API. Also, it would be great to have as less as possible stuff going<br />
on between invocation of Scene::Window::performPaint() and getting the<br />
corresponding pixel data on the screen.</p>

<p>There is a good chance that the new padding stuff may make you vomit. If<br />
it does so, I'm all ears for the suggestions how to make the code more<br />
nicer.</p>

<p>BUG: 257566<br />
BUG: 360549<br />
FIXED-IN: 5.18.0</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R108 KWin</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D25611">https://phabricator.kde.org/D25611</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>decorations/decorationrenderer.cpp<br />
decorations/decorationrenderer.h<br />
plugins/scenes/opengl/scene_opengl.cpp<br />
scene.cpp</div></div></div><br /><div><strong>To: </strong>zzag, KWin<br /><strong>Cc: </strong>kwin, fvogt, LeGast00n, The-Feren-OS-Dev, sbergeron, jraleigh, fbampaloukas, GB_2, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart<br /></div>