Description: I open a document with 32 pages and about 25 linked png or jpg images which were created in the previous version (5.3) of LibreOffice. Then I add another png image (about 1900x1000pixels) (checking the 'link' checkbox) and start typing below it (wrap is set to 'optimal page wrap'). Initially everything is fine. Then suddenly typing slows to a crawl. I can see the image being repainted. It starts to become impossible to type. I scroll up and start typing above the image. Now I can type at normal speed. I go several pages down (below the inserted image) and try typing there. Everything is fine. I scroll back up below the inserted image. Initially I can type at normal speed. Then it goes back to slow typing again. The problem only seems to happens with the newly added image. I have similar images in the same document that were added with the previous version of LibreOffice. I can add text at normal speed below them without problem. The problem does not seem to be related to the linking of the image. When I insert the image without linking it, the same slowdown occurs. Unfortunately I can not attach the document. Steps to Reproduce: 1. Open many-page document in Writer. 2. Insert a larger png image somewhere in the middle (with optimal page wrap) 3. Start typing below the image. Actual Results: Image repaints itself (blinks) when typing Typing slows to a crawl. Expected Results: Typing speed should be normal. Reproducible: Always User Profile Reset: No Additional Info: Running on Windows 7 x64 I have set severity to major because this problem makes writer unusable for larger documents. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
*** Bug 113966 has been marked as a duplicate of this bug. ***
Created attachment 137934 [details] Text document with 7 MB image for typing-delay testing I have attached a 4 page odt document with an image on page 2 for testing the issues. When I open this document, scrolling and typing additional text on the first page works fine. When after scrolling down until the image appears, scrolling becomes sluggish. With the image on page 2 is in sight, typing text (on page 2) appears very, very slow. when scrolling further down until the image is no longer visible, both scrolling and typing are fine again.
I can repro with the document. On a fast system, it is best tested by holding down a key and listening to the CPU fans rev up. No CPU strain or slowness observed with 3.6.7 Arch Linux 64-bit Version: 6.0.0.0.alpha1+ Build ID: 1d9eed341db208f11de6f020538dfdb74a5c48dd CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded Built on November 22nd 2017 Arch Linux 64-bit Version 3.6.7.2 (Build ID: e183d5b)
*** Bug 113971 has been marked as a duplicate of this bug. ***
(In reply to Buovjaga from comment #5) > *** Bug 113971 has been marked as a duplicate of this bug. *** See callgrind trace from that bug, attachment 137894 [details]
and in Versie: 4.2.0.4 Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71 but not in Versie: 4.1.0.4
Not reproducible for me with the attached test-file and LibreOffice 6.0.3.0+ under Ubuntu 16.04 x86-64, OpenGL being disabled. Version: 6.0.3.0.0+ Build ID: 7b8516ac7fc0c4d91b1439626a334fd0778680c7 Threads CPU : 4; OS : Linux 4.4; UI Render : par défaut; VCL: gtk3; Ubuntu_16.04_x86-64 Locale : fr-FR (fr_FR.UTF-8); Calc: threaded Best regards. JBF
I don't see any repainting, nor experiencing actual slowness (anymore). However, the CPU usage is still pretty extreme for holding down key below the image.. Version: 6.1.0.0.alpha0+ Build ID: fb29e6eeeaad5255bb924ff59162a83ed80bfb0a CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-03-09_03:14:44 Locale: nl-NL (nl_NL); Calc: CL
After bisecting on Linux with 42max, we now have the original cause: commit 11c6c0fb4a3cc3f394b37b7a0a53eb0ad39912dc Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Sep 5 22:40:21 2015 +0800 source-hash-2e5167528f7566dd9b000e50fc1610b7bf99132a commit 2e5167528f7566dd9b000e50fc1610b7bf99132a Author: Armin Le Grand <alg@apache.org> AuthorDate: Thu Oct 31 14:43:21 2013 +0000 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Tue Nov 5 15:24:18 2013 +0000 Resolves: #i123500# unified Graphic processing to use GraphicPrimitive2D (cherry picked from commit f5d69b2b8b002ca6905496a9d9065ef76b5641d7) Adding Cc: to Armin Le Grand.
*** Bug 118952 has been marked as a duplicate of this bug. ***
(In reply to Telesto from comment #9) > I don't see any repainting, nor experiencing actual slowness (anymore). > However, the CPU usage is still pretty extreme for holding down key below > the image.. No repro.. everything appears to be fine Version: 6.3.0.0.alpha0+ Build ID: 20ea90a557b5bc744fd234e3a20ab1db484cf88b CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-03-22_03:21:58 Locale: nl-NL (nl_NL); UI-Language: en-US Calc: threaded
Well, that was a nice surprise. I confirm the CPU is nowhere near maxing out now. Arch Linux 64-bit Version: 6.2.2.2 Build ID: 6.2.2-1 CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: kde5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded