Bug 112568 - Slow typing in Writer after inserting png image, image repaints all the time
Summary: Slow typing in Writer after inserting png image, image repaints all the time
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, haveBacktrace, perf, regression
: 113966 113971 118952 (view as bug list)
Depends on:
Blocks: Writer-Images CPU-AT-100% Regressions-GraphicPrimitive2D
  Show dependency treegraph
 
Reported: 2017-09-22 10:14 UTC by Felix Stadler
Modified: 2019-03-25 10:52 UTC (History)
6 users (show)

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


Attachments
Text document with 7 MB image for typing-delay testing (7.24 MB, application/vnd.oasis.opendocument.text)
2017-11-23 07:41 UTC, GAJ
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Stadler 2017-09-22 10:14:56 UTC
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
Comment 1 Xisco Faulí 2017-09-22 23:17:25 UTC
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.)
Comment 2 Buovjaga 2017-11-21 09:43:59 UTC
*** Bug 113966 has been marked as a duplicate of this bug. ***
Comment 3 GAJ 2017-11-23 07:41:56 UTC
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.
Comment 4 Buovjaga 2017-11-23 15:13:11 UTC
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)
Comment 5 Buovjaga 2017-11-23 17:14:58 UTC
*** Bug 113971 has been marked as a duplicate of this bug. ***
Comment 6 Buovjaga 2017-11-23 17:16:03 UTC
(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]
Comment 7 Telesto 2018-01-28 14:58:00 UTC
and in
Versie: 4.2.0.4 
Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71

but not in
Versie: 4.1.0.4
Comment 8 Jean-Baptiste Faure 2018-03-11 11:57:58 UTC
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
Comment 9 Telesto 2018-03-11 12:59:41 UTC
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
Comment 10 Buovjaga 2018-07-07 19:00:14 UTC
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.
Comment 11 Buovjaga 2018-09-02 13:57:00 UTC
*** Bug 118952 has been marked as a duplicate of this bug. ***
Comment 12 Telesto 2019-03-25 10:42:22 UTC
(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
Comment 13 Buovjaga 2019-03-25 10:52:03 UTC
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