When you save a document, for some reason one or two seconds into the save operation, Writer hides any visible comments, redrawing them only when the save is complete. If you're reading a long comment while a save completes (which can take a long time), it means you just have to wait before you can continue reading the comment. I don't understand why Writer goes to the trouble of redrawing the window with comments hidden from display, soon after the start of the save. It's a small counterproductive action, in my opinion. Unless there's a good reason for it, perhaps the hide and redraw could be removed?
I should add, Writer only seems to do this for .odt format files, not .docx files.
I would consider this as a bug and not as an enhancement request. Just for clarification: It happens during autosave, right? Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? => NEEDINFO
Created attachment 166963 [details] Sample document I thought it happened during manual save, but try that just now (but with v7.0.2.2), it did NOT happen. But I just now tried it with autosave in that version, and it did not occur for autosave either. Because I had Track Changes turned on (Record and Show) when the problem occurred, I wondered whether that was a prerequisite, but just tested that now (manual and autosave), and again the problem did not occur. I had almost given up trying to reproduce when I was able to, in 7.0.2.2. In fact the bug does not appear under autosave, only under manual save. I scrolled to a page with 3 comments, one of which was long and had a scrollbar, and all comments vanished about 1-2 seconds after the Save I called for, started. See attached sample document, obfuscated. Steps: 1. Go to page 309 (printed page 301) 2. Check that Record and Show changes are on. 3. Make a change 4. Save the file Note that about a second into the save, all comments are erased.
I've opened your attachment There was no comment o page 309, so I used page 308 (307 to print) with one comment and couldn't reproduce it with Version: 7.0.3.1 (x64) Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: threaded Document contains 526 comments and that makes document almost unusable (see bug 60418 or bug 61558). so I assume, that the problem only occurs in a document with many comments.
Just looking into that. Sorry, yes, after obfuscation, the page to use is p318 (printed page 310), which has four comments,two with scrollbars. I also note that there's been a major performance regression in 7.0.2.2 for opening that file, compared to 6.4.2.2 - in the new version, opening on my Linux system the sample file took 4 - 5 mins; in 6.4.2.2 it opened in about 30 seconds. Saving is also far slower in 7.0.2.2, taking 90 seconds. (My estimate is it took about 20-30 seconds in 6.4.2.2.) How did you discover the number of comments, as a matter of interest? I have an enhancement request in to add # of comments to the document properties statistics tab. This version of the document has about half the comments of an earlier version: during the 6.x series of Writer, the performance of documents with many comments (e.g. a novel in discussion with an editor, a very standard workflow), improved enough to be usable. I note, finally, that even using the same page you did, (308), the comment disappeared when I saved the file.
As Dieter pointed out, seems consequence of known comments issue. The number of comments is seen in Navigator, hovering over Comments. As for other issues, speed, you may open a new bug, but please refrain until you find out exactly where slowing happened. If in Linux, you may easily use 1-file versions from https://libreoffice.soluzioniopen.com/. Please also search if already reported. *** This bug has been marked as a duplicate of bug 60418 ***
I don't see how this issue relates in any way to the bugs Dieter noted, 60418 or 61558. This report is that the comments are removed from display when a manual save is performed, and re-drawn only when the save is completed. I don't see that the erasure and redraw of comments is an aspect of those bugs. This bug/enhancement seems unrelated, to me, and should be left as not resolved I think. I guess I'm just saying I don't see why slow performance would cause the code to hide and then redraw comments - unless you're saying comments are hidden and redrawn constantly, for any editing or scrolling operation (or save), and the redraw happens to not occur before the save. That seems unlikely though, to me.
(In reply to Luke Kendall from comment #7) > I don't see how this issue relates in any way to the bugs Dieter noted, > 60418 or 61558. It's unrelated to bug 60418 and bug 61558, IMHO. If though this file combines quite a lot of evil :-) 500 pages Many comments in document Comments visible in screen (not hidden) Track & Changes enabled Track & Changes visible Multipage view Maybe even GTK3 being somehow included in this... So summary -> File open speed slowed down with 7.1. For me 4.4.7.2 and 5.3 pretty fast. 6.0 appears to be slower already.. so introduced over time -> Scrolling the document being very slow single page with changes + comments hidden in 7.1 and in 6.0. Scrolling being snappier in 5.3.. but still showing tearing.. even better in 5.2 (Text Layout Engine?) -> Scrolling using quite bunch of CPU usage even in 5.2 and 5.0 (more compared to what I would expect) with hidden changes and comments - Showing changes makes 5.2 slower. Subtle impression 5.0 being faster with changes shown. Showing changes + comments unusable slow (single page). Deleting all comments and speed is back to normal Hidden comments and scrolling with or without showing track changes fast with 4.4.7.2. With comments on and view changes on at the same time slow. Only showing changes or only showing comments fine. Multi page mode is pretty fast even with comments & track changes visible I would speculate they improved timers are they cause..(Tobias Madl + Meeks) Painting they comment box more often. And somehow track & changes and comments got entangled. 5.0.6.3 is already affected by slows while scrolling
Luke and Telesto: point of bugs IMO is not to make a lot of them and flood BZ, but to expect resolution for small bugs and to build momentum for heavy bugs - like 60418. Maybe (judging by your reports) you don't share my view. How could anyone resolve this (consequence) bug when handling (drawing) comments is flawed. So key question is: will any dev take this file and resolve this issue? My QA experience tells "no". So having this separate bug is pointless. Just CC to 60418. If you both cannot code, next biggest contribution is bibisect. LO is full of regressions, unfortunately. Like this speed issue: slower over time. Finding that regression is most daunting of bibisects. So if you can do it (in another bug, if not found before), great. Problem with Fileopen times is that there are 2: - time to see document - time to count all comments Please make detailed test, indicating clearly exact version where slowed down - which is e prerequisite for bibisect.
Created attachment 166993 [details] Faster to open (for testing)
Status update. They file open slows down on Windows not in bibisect-6.3 master (x32) but in win64-6.4 oldest With 6.3 master it takes 80 seconds until document being shown on screen and with 6.4 oldest 120 seconds and with 7.1 110 With 5.0 master it's 74 seconds