Created attachment 183630 [details] Screenshot of the problem See attached image for more details. Notice that beside the line numbers there's a rendering glitch showing some information that shouldn't be there. It happens in light and dark modes. It seems to be kf5-only (could not reproduce with gtk3). I've been noticing this issue at least since 7.3.x, but it could have started earlier. Version: 7.3.6.2 / LibreOffice Community Build ID: c28ca90fd6e1a19e189fc16c05f8f8924961e12e CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: CL Also repro with Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c4308f9249b7209ff39f5b202bcd5237d84416e8 CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: CL threaded
Reproduced in: Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: deb7bc82de19ea8e20c767fdf21f9ba4feb5e9f0 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded I can make the issue appear by resizing the object catalog on the left, or by undocking the object catalog. Also in: Version: 7.0.6.2 Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 Locale: de-DE (en_AU.UTF-8); UI: en-US Calc: threaded I assume "inherited from OOo" was an error?
After taking a long look at the code I found out what the problem is... but fixing it might be a bit more complicated than I thought. The problem is with how WB_BORDER is dealt with in windows created using the kf5 backend. This bug report is affected by two such windows: 1) The "window" that has the line numbers: https://opengrok.libreoffice.org/xref/core/basctl/source/basicide/linenumberwindow.cxx?r=0d9231f2#20 2) The "window" containing the code editor https://opengrok.libreoffice.org/xref/core/basctl/source/basicide/baside2b.cxx?r=be6024a2#243 Note that both are created using the WB_BORDER flag so that a thin border is drawn around the window. The problem is that, for some reason, in kf5 the border is drawn with an additional "black" outer border line with 1 pixel in size. Then when the window is resized (f.i. when the line number window needs more width) and the Editor Window is moved to the right, the remnants of the previously drawn window that was below the black pixels stay there. They never get removed. To test this, simply remove the WB_BORDER flag and you'll notice that the problem disappears (as well as the borders...). This makes me wonder if the problem is a bit deeper and relates to how window borders are drawn in general. I would like to get some input from devs to see if my assessment is correct... and maybe point to some direction to provide a definitive fix for this issue.
@Michael, could you please give your take on this issue? (see Comment #2) I did a lot of trial and error to try to fix this problem, but I was not successful. Maybe you can point me to another direction. It seems in kf5 window borders are not redrawn and whatever remnants of what was behind are not replaced by the window border.
@Rafael: Thanks for that detailed analysis! The exact behavior depends on the Qt style in use. Breeze defines a 2 pixel border, but only the "inner row" of pixels is an actual border, the outer row of pixels is a margin (s.a. tdf#138010), and the artifacts are apparently exactly at the location where that margin is. Further testing/experimenting confirms that the issue goes away when explicitly drawing something there. In a local test, adding something like this to `ImplSmallBorderWindowView::DrawWindow` made it work as expected: Color aOrigFillColor = rRenderContext.GetFillColor(); Color aOrigLineColor = rRenderContext.GetLineColor(); rRenderContext.SetLineColor(rRenderContext.GetBackgroundColor()); rRenderContext.SetFillColor(rRenderContext.GetBackgroundColor()); rRenderContext.DrawRect(tools::Rectangle(Point(0, 0), rRenderContext.GetOutputSize())); rRenderContext.SetFillColor(aOrigFillColor); rRenderContext.SetLineColor(aOrigLineColor); I'm not 100% sure what is the best place to ensure that this gets redrawn, but after some further analysis, I've come up with a change that does sth similar to the above in the qt-specific code, similar to what gtk3 also does: https://gerrit.libreoffice.org/c/core/+/146419
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6f4b8b7cfe2907b7da46eec6951a0e09b836a6de tdf#152073 qt: Draw background when drawing frame It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/7a6cbff566122113b753fd31e7c73be8725f48f2 tdf#152073 qt: Draw background when drawing frame It will be available in 7.5.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Michael Weghorn from comment #4) > I'm not 100% sure what is the best place to ensure that this gets redrawn, > but after some further analysis, I've come up with a change that does sth > similar to the above in the qt-specific code, similar to what gtk3 also does: > https://gerrit.libreoffice.org/c/core/+/146419 Turns out removing transparency whenever drawing a frame is problematic, s. tdf#153895 (regression from the commit). Alternative solution including a revert of the original commit now pending in Gerrit: https://gerrit.libreoffice.org/c/core/+/148117
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/699a1745f30cc0e89d59c6fc6ea742da5ff0ccea tdf#152073 tdf#153895 basicide: Set bg color for border win It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/41570cf09b171a6ee1f04d39dd72399e2726d381 tdf#152073 tdf#153895 basicide: Set bg color for border win It will be available in 7.5.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.