[Libreoffice-bugs] [Bug 131004] New: Unstable paint of writer consecutive section frames

[bugzilla-daemon at bugs.documentfoundation.org]

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

            Bug ID: 131004
           Summary: Unstable paint of writer consecutive section frames
           Product: LibreOffice
           Version: 6.1.6.3 release
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Writer
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: glogow at fbihome.de

Created attachment 158250
  --> https://bugs.documentfoundation.org/attachment.cgi?id=158250&action=edit
Document with three consecutive sections.

Open the attached document. It contains the explaining text and three
consecutive sections with minimal content, so it's easier to test. What can be
observed is the following. As far as I can say, this doesn't depend on zooming.
The only stable behavior is: remove the 2nd section and the top border of the
3rd section moves by a pixel, or sometimes vanishes completely.

Sometimes you have a double / two pixel border on load. This is sometimes even
triggered by a reload.

Change the 2nd section in any of the following ways:
    • add a line
    • remove a line
    • remove the whole 2nd section via Format > Sections… „Bereich 2“

Results can be one of the following:
    • 3rd section top border moves by a pixel
(always happens when the  2nd section is removed – best observed via undo +
redo)
    • 3rd section top border isn‘t painted at all, until refresh like scrolling
out of view (seldom)
    • 1st section bottom border / 2nd section top border result in two lines
(seldom)

Eventually some merging of borders is happening.

>From the layout definition, they don't take any space, which IMHO makes sense.
These frames just act as a visible hint and don't affect the layout. So maybe
all sections should simply draw their frames, so for consecutive sections,
these are always doubled? But probably we still need some extra handling, if
the device pixels match to the same line.

The worst problem, and the origin of this report, is the missing top border of
the 3rd section on delete, which should never happen. That looks like a refresh
problem, but it isn't. The border is simply not painted, because Writer doesn't
realize the upper border needs repaint. In the debugger I can see, that no
painting for this line happens at all, but happens in the correct case in
SwSubsRects::PaintSubsidiary. If the user triggers a new paint of the section
(scroll the section out of view, minimize+restore, ...), the border becomes
visible.

I think, this is basically all the same bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200228/15e91e0a/attachment.htm>