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
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
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.
A duplicate of bug 108553(and bug 107305)
(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?
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.
(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.
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.
(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.
(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
(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%?
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.
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
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.
(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.
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. :-)
*** Bug 121243 has been marked as a duplicate of this bug. ***
(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.
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.
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
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
*** Bug 107305 has been marked as a duplicate of this bug. ***
*** Bug 108553 has been marked as a duplicate of this bug. ***
(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