https://bugs.documentfoundation.org/show_bug.cgi?id=152073

Michael Weghorn <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|[email protected] |[email protected]
                   |desktop.org                 |

--- Comment #4 from Michael Weghorn <[email protected]> ---
@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

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to