Bug 117180 - Dashed lines of the hard page break separator in Writer appears only, if you scroll or zoom in/out
Summary: Dashed lines of the hard page break separator in Writer appears only, if you ...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0.2.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, implementationError
: 107305 108553 121243 (view as bug list)
Depends on:
Blocks: Writer-Page-Break
  Show dependency treegraph
 
Reported: 2018-04-23 13:36 UTC by xordevoreaux
Modified: 2019-10-16 20:43 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description xordevoreaux 2018-04-23 13:36:16 UTC
Description:
Hard page break separators in Writer render very slowly. Length of the document does not matter.

Steps to Reproduce:
1.Open Writer
2.Type some text
3.Enter a hard page break
4.Scroll across the page break

Actual Results:  
When scrolling down over a hard page break, the dotted line of the page break crawls across the screen very slowly.

Expected Results:
The hard page break's dashed line should render instantly.


Reproducible: Always


User Profile Reset: No



Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 OPR/52.0.2871.64
Comment 1 Dieter 2018-04-23 13:55:01 UTC
I can reproduce it with

Version: 6.1.0.0.alpha0+ (x64)
Build ID: 2325f9ac789cd12e5ecc9d239baf2558e1d678bb
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-04-05_00:37:47
Locale: en-US (de_DE); Calc: CL

1. Open writer
2. Enter page break (STRG + Enter)

Actual result:
page break line is only visible, if you scroll across the document or iff you zoom in or out

Expected result:
Page break line should be visible directly after page break


Not reproducible in

Version: 5.4.6.2 (x64)
Build-ID: 4014ce260a04f1026ba855d3b8d91541c224eab8
CPU-Threads: 4; BS: Windows 6.19; UI-Render: Standard; 
Gebietsschema: en-US (de_DE); Calc: group
Comment 2 xordevoreaux 2018-04-23 17:45:50 UTC
The biggest issue with it is that it slows down scrolling. You scroll through pages where there's a hard page break, the entire scrolling process stops until the dashes of the page break renders.
Comment 3 xordevoreaux 2018-04-23 17:46:37 UTC Comment hidden (obsolete)
Comment 4 Telesto 2018-04-23 18:39:37 UTC
A duplicate of bug 108553(and bug 107305)
Comment 5 Dieter 2018-04-23 19:35:45 UTC
(In reply to mwtjunkmail from comment #3)
> The biggest issue with it is that it slows down scrolling. You scroll
> through pages where there's a hard page break, the entire scrolling process
> stops until the dashes of the page break renders.

So perhaps we better should differ between these two issues?
Comment 6 xordevoreaux 2018-04-23 19:48:42 UTC
They're one in the same. I have bad eyes so I always view documents at 120% or 130%. The visibility and rendering speed of the dashed line is probably sourced from the same problem.
Comment 7 Dieter 2018-04-23 20:39:52 UTC
(In reply to Telesto from comment #4)
> A duplicate of bug 108553(and bug 107305)

Telesto, I disagree, because it works fine with LO 5.4.6.2, whereas bug 107305 is reproducible with LO 5.4.
Comment 8 xordevoreaux 2018-04-24 12:25:14 UTC
For whatever reason, someone changed the title of the bug I posted.
I originally complained about the dashed line of the page separator rendering slowly, and that was in the title.

Then someone changed it to read zoom in/out. It's not the appearing and disappearing that causes a problem, although that might be an issue, I don't zoom in and out, I'm always zoomed in, it's that the page break interrupts the scroll because it takes too long.  

You're scrolling, scrolling, scrolling, down pages, and then you're not because you hit a hard page break. I don't remember experiencing this as an issue in 6.0.2.
Comment 9 Dieter 2018-04-24 13:10:21 UTC
(In reply to mwtjunkmail from comment #8)
> For whatever reason, someone changed the title of the bug I posted.

Yes I changed the title, because it happens not only with scrolling, but also with zoom in/out.
Comment 10 Telesto 2018-04-24 17:53:51 UTC
(In reply to Dieter Praas from comment #7)
> (In reply to Telesto from comment #4)
> > A duplicate of bug 108553(and bug 107305)
> 
> Telesto, I disagree, because it works fine with LO 5.4.6.2, whereas bug
> 107305 is reproducible with LO 5.4.

The behavior is a more obvious in 6.0, for some reason. However the problem is already present in 5.4 (at least in my opinion). Set it to zoom-level 70% and press CTRL+Enter a few times. Some of the page breaks are missing.. 

@mwtjunkmail@gmail.com
Does this also happen in safe mode (Help -> Restart in Safe mode -> Continue in safe mode) I'm not noticing any slowness with the dotted page break line
Comment 11 xordevoreaux 2018-04-25 13:20:26 UTC
(In reply to Telesto from comment #10)
> (In reply to Dieter Praas from comment #7)
> > (In reply to Telesto from comment #4)
> > > A duplicate of bug 108553(and bug 107305)
> > 
> > Telesto, I disagree, because it works fine with LO 5.4.6.2, whereas bug
> > 107305 is reproducible with LO 5.4.
> 
> The behavior is a more obvious in 6.0, for some reason. However the problem
> is already present in 5.4 (at least in my opinion). Set it to zoom-level 70%
> and press CTRL+Enter a few times. Some of the page breaks are missing.. 
> 
> @mwtjunkmail@gmail.com
> Does this also happen in safe mode (Help -> Restart in Safe mode -> Continue
> in safe mode) I'm not noticing any slowness with the dotted page break line

I haven't tried it safe mode, but have you tried scrolling over hard page breaks at 120% and not just 70%?
Comment 12 Buovjaga 2018-06-05 18:44:23 UTC
I bibisected in bibisect-win32-5.3 for these steps

1. Set zoom to 70%
2. Ctrl-Enter three times

The page break dashed line is not visible starting from the third entered break. Scrolling makes it visible.

This was blamed: https://cgit.freedesktop.org/libreoffice/core/commit/?id=27ee9ee8e816334447f1cf781bc2892469e0c8dc

	Stephan Bergmann <sbergman@redhat.com>	2016-11-14 17:48:56 +0100
commit 27ee9ee8e816334447f1cf781bc2892469e0c8dc (patch)
tree e31a6269e1d26325f96fa4eccbf00d96eb6c950c
parent b6ce0cd83afaab1bc03f7421745ff752c3459e99 (diff)
Don't AlignToPixel in SwView::SetVisArea
When e.g. inserting a Writer doc in a Calc doc ("Insert - Object - OLE Object...
- Create new - LibreOffice 5.3 Text" in Calc), the resulting .ods contains the
size of the embedded Writer doc in two places.

Change-Id: I755dd9e8b2406f0b4b41d0f3d1281d6ad4b1b238

I tried reverting it on Linux, but I could not get it to build (related stuff has changed).
It kind of sounds like a wrong result.

For some reason, I could already repro the disappearing page break in a release build of 5.0.2.2 on Windows. That is why I found it confusing that I had to go to bibisect repo 5.3 as all the older ones worked fine.
Comment 13 Aron Budea 2018-09-30 02:10:31 UTC
My result with repo bibisect-win32-5.1 is below (buovjaga, thanks for the steps). Adding Cc: to Miklos Vajna.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=af11abf3626e12d2b4b7dd9d255c6c71bf84cd4b
author		Miklos Vajna <vmiklos@collabora.co.uk>	2015-09-01 11:41:39 +0200
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2015-09-01 12:00:24 +0200

"SwViewShell::ImplEndAction: still paint directly when non-double-buffering"

Commit was also backported to 5.0 in time for 5.0.2:
https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-5-0&id=5e2ed069da0b21ee7f0e5f52b9ace5c98c12f0f9
Comment 14 Miklos Vajna 2018-10-16 07:34:23 UTC
Sorry, I think this is rather an implementation error than a true regression. We always used to paint those separator directly, then I tried to switch to invalidate-then-idle-paint, that uncovered lots of problems, so I quickly went back to the original behavior. Now this bugreport claims that the paining of those separator "regressed", just because there was a small window in time when they behaved better (ignoring the fact that it had larger downsides).

So yes, this is a problem, it has to be fixed, but it's not new in any way, I would say.
Comment 15 Aron Budea 2018-11-07 13:35:47 UTC
(In reply to Miklos Vajna from comment #14)
> Sorry, I think this is rather an implementation error than a true
> regression. We always used to paint those separator directly, then I tried
> to switch to invalidate-then-idle-paint, that uncovered lots of problems, so
> I quickly went back to the original behavior. Now this bugreport claims that
> the paining of those separator "regressed", just because there was a small
> window in time when they behaved better (ignoring the fact that it had
> larger downsides).
The separator was visible in older releases. I can't say whether there were fundamental issues with painting the separator, just there was no visible effect, or whether a combination of changes between 5.0 and 5.1 brought this forward, and the identified commit isn't directly responsible. Further explanation of the situation would be welcome.
Comment 16 Miklos Vajna 2018-11-07 16:09:22 UTC
Indirect painting happened between 2015-06-29 and 2015-09-01. Perhaps it would be interesting to see if the current broken behavior was there already in "beb4aa21d61f0d66392d596be86fb57b4b167239^" or not yet in "af11abf3626e12d2b4b7dd9d255c6c71bf84cd4b"?

That would explain why bisect finds the above commit, as bisect only works nicely when the range is short enough that only one thing changes. :-)
Comment 17 Telesto 2018-11-07 16:14:05 UTC
*** Bug 121243 has been marked as a duplicate of this bug. ***
Comment 18 Aron Budea 2018-11-07 16:31:15 UTC
(In reply to Miklos Vajna from comment #16)
> Indirect painting happened between 2015-06-29 and 2015-09-01. Perhaps it
> would be interesting to see if the current broken behavior was there already
> in "beb4aa21d61f0d66392d596be86fb57b4b167239^" or not yet in
> "af11abf3626e12d2b4b7dd9d255c6c71bf84cd4b"?
> 
> That would explain why bisect finds the above commit, as bisect only works
> nicely when the range is short enough that only one thing changes. :-)
I used steps from bug 108553, because it's extremely simple, and should be the same thing (and bug 107305 should be the same as well): press Ctrl+Enter once at 100% zoom.

The bibisect repo I used was lo-linux-dbgutil-daily-till51 this time, 2015-06-29, 2015-06-30 and 2015-09-01 were bug-free (separator was visible), while 2015-09-02 had the bug (no separator shown right away). I'm afraid we're where at we started.
Comment 19 xordevoreaux 2019-10-15 15:10:40 UTC
I'm using 6.3.3.1 and regardless of % zoom, how many hard page breaks I have, or how fast I try to scroll, I'm not seeing any slow-down, and the page break line is always displayed (although it blinks quickly during redraw but big deal).

Windows 10 Pro 64-bit. 
I'm not using OpenGL.
Comment 20 Dieter 2019-10-15 15:14:55 UTC
Also works fine with OpenGL enabled and

Version: 6.4.0.0.alpha0+ (x64)
Build ID: 460908269972fd1f89312a1e62897ed1503e9e98
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-09-30_09:18:03
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded
Comment 21 Aron Budea 2019-10-15 15:35:29 UTC
Indeed, thanks for retesting.
Reverse bibisecting points to the following fixing commit:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=00dfa6dc890dbbc8140fe613599becb5e4c55486
author		Miklos Vajna <vmiklos@collabora.com>	2019-06-07 11:12:31 +0200
committer	Miklos Vajna <vmiklos@collabora.com>	2019-06-07 14:17:10 +0200

tdf#117347 sw form controls: fix disappearing FixedText when editing TextField
Comment 22 Aron Budea 2019-10-15 15:39:54 UTC
*** Bug 107305 has been marked as a duplicate of this bug. ***
Comment 23 Aron Budea 2019-10-15 15:49:46 UTC
*** Bug 108553 has been marked as a duplicate of this bug. ***
Comment 24 Dieter 2019-10-16 20:43:07 UTC
(In reply to Aron Budea from comment #21)
> Indeed, thanks for retesting.
> Reverse bibisecting points to the following fixing commit:
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=00dfa6dc890dbbc8140fe613599becb5e4c55486
> author		Miklos Vajna <vmiklos@collabora.com>	2019-06-07 11:12:31 +0200
> committer	Miklos Vajna <vmiklos@collabora.com>	2019-06-07 14:17:10 +0200
> 
> tdf#117347 sw form controls: fix disappearing FixedText when editing
> TextField

=> VERIFIED FIXED