SUMMARY At some vertical positions a single pixel gap can appear between window decorations and window content, showing whatever is directly behind the window. STEPS TO REPRODUCE 1. Set fractional scale factor (currently using 1.4x) 2. Create a window (reproduced with Settings window) 3. Move window vertically in small increments OBSERVED RESULT A transparent gap appears between the window decoration and window content at some positions, disappears for others EXPECTED RESULT No gap appears, window stays opaque at all points within outer bounds of border. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.3.1-arch1-1, 64bit (available in About System) KDE Plasma Version: 5.16.90 KDE Frameworks Version: 5.62.0 Qt Version: 5.13.1 ADDITIONAL INFORMATION * this does not appear for me with integer scaling factors * external photo included rather than screenshot as spectacle segfaults for me at the moment 🤷
Created attachment 122998 [details] Image of gap
*** Bug 412969 has been marked as a duplicate of this bug. ***
It can be a std::floor() vs std::round() issue. Or a texture bleeding issue.
*** Bug 414655 has been marked as a duplicate of this bug. ***
Created attachment 124253 [details] Screenshot of the issue Same problem here. Attaching screenshot where a similar issue can be seen even on the left side.
Git commit ac4dce1c20a1cbfd3974bf8da6dd7557d35a4ca1 by Vlad Zahorodnii. Committed on 02/12/2019 at 13:08. Pushed by vladz into branch 'master'. [scene] Fix decoration texture bleeding Summary: Quite long time ago, window decorations were painted on real X11 windows. The nicest thing about that approach is that we get both contents of the client and the frame window at the same time. However, somewhere around KDE 4.2 - 4.3 times, decoration rendering architecture had been changed to what we have now. I've mentioned the previous decoration rendering design because it didn't have a problem that the new design has, namely the texture bleeding issue. In the name of better performance, opengl scene puts all decoration parts to an atlas. This is totally reasonable, however we must be super cautious about things such as the GL_LINEAR filter. The GL_LINEAR filter may need to sample a couple of neighboring texels in order to produce the final texel value. However, since all decoration parts now live in a single texture, we have to make sure that we don't sample texels that belong to another decoration part. This patch fixes the texture bleeding problem by padding each individual decoration part in the atlas. There is another solution for this problem though. We could render a window into an offscreen texture and then map that texture on the transformed window geometry. This would work well and we definitely need an offscreen rendering path in the opengl scene, however it's not feasible at the moment since we need to break the window quads API. Also, it would be great to have as less as possible stuff going on between invocation of Scene::Window::performPaint() and getting the corresponding pixel data on the screen. There is a good chance that the new padding stuff may make you vomit. If it does so, I'm all ears for the suggestions how to make the code more nicer. Related: bug 257566, bug 360549 FIXED-IN: 5.18.0 Reviewers: #kwin Subscribers: fredrik, kwin, fvogt Tags: #kwin Differential Revision: https://phabricator.kde.org/D25611 M +6 -1 decorations/decorationrenderer.cpp M +1 -0 decorations/decorationrenderer.h M +108 -9 plugins/scenes/opengl/scene_opengl.cpp M +11 -4 scene.cpp https://commits.kde.org/kwin/ac4dce1c20a1cbfd3974bf8da6dd7557d35a4ca1
Git commit af71763be53054925f27b7614fc992e6380a1d02 by Vlad Zahorodnii. Committed on 09/01/2020 at 13:13. Pushed by vladz into branch 'master'. [scene] Fix decoration texture bleeding Summary: Quite long time ago, window decorations were painted on real X11 windows. The nicest thing about that approach is that we get both contents of the client and the frame window at the same time. However, somewhere around KDE 4.2 - 4.3 times, decoration rendering architecture had been changed to what we have now. I've mentioned the previous decoration rendering design because it didn't have a problem that the new design has, namely the texture bleeding issue. In the name of better performance, opengl scene puts all decoration parts to an atlas. This is totally reasonable, however we must be super cautious about things such as the GL_LINEAR filter. The GL_LINEAR filter may need to sample a couple of neighboring texels in order to produce the final texel value. However, since all decoration parts now live in a single texture, we have to make sure that we don't sample texels that belong to another decoration part. This patch fixes the texture bleeding problem by padding each individual decoration part in the atlas. There is another solution for this problem though. We could render a window into an offscreen texture and then map that texture on the transformed window geometry. This would work well and we definitely need an offscreen rendering path in the opengl scene, however it's not feasible at the moment since we need to break the window quads API. Also, it would be great to have as less as possible stuff going on between invocation of Scene::Window::performPaint() and getting the corresponding pixel data on the screen. There is a good chance that the new padding stuff may make you vomit. If it does so, I'm all ears for the suggestions how to make the code more nicer. Related: bug 257566, bug 360549 FIXED-IN: 5.18.0 Reviewers: #kwin Subscribers: fredrik, kwin, fvogt Tags: #kwin Differential Revision: https://phabricator.kde.org/D25611 M +6 -1 decorations/decorationrenderer.cpp M +1 -0 decorations/decorationrenderer.h M +108 -9 plugins/scenes/opengl/scene_opengl.cpp M +11 -4 scene.cpp https://commits.kde.org/kwin/af71763be53054925f27b7614fc992e6380a1d02
*** Bug 418879 has been marked as a duplicate of this bug. ***
This should be fixed now, please reopen if you can still find it.