Bug 123165 - Slow typing in document with pictures (gtk3 under X)
Summary: Slow typing in document with pictures (gtk3 under X)
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.1.3.2 release
Hardware: All Linux (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: target:6.3.0 target:6.2.1
Keywords: haveBacktrace, perf
Depends on: Regressions-GraphicPrimitive2D
Blocks: GTK3
  Show dependency treegraph
 
Reported: 2019-02-04 20:59 UTC by Telesto
Modified: 2021-02-10 15:10 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Testfile for the picture bug (24.16 KB, application/vnd.oasis.opendocument.text)
2019-02-05 07:25 UTC, Frank Steiner
Details
picture used in the test file (125.80 KB, image/jpeg)
2019-02-05 07:25 UTC, Frank Steiner
Details
Callgrind output from master (1.11 MB, application/x-xz)
2019-02-05 12:21 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2019-02-04 20:59:19 UTC
Description:
From bug 104716 comment 52

Just moved from SLE 12 to SLE 15, and while both have libreoffice-6.1.3.2, SLE 15 uses libreoffice-gtk3 instead of -gtk2. And now we can no longer work with documents having a few pictures.

Steps to Reproduce:
Just added three copies of a pictures with 1/3 the width of the page (all linked to the same pic file on the disk) in one row. Copied it so that we get 5 rows, i.e. 15 pics.

When we scroll the document so that we have only 3 or none pics in the viewport, we can type in normal speed. When we see 6 pics in the viewports, typing already shows some glitches and delays. With 9 pics visible, whole words are delayed, i.e., we type a full sentence in normal speed and the words appear 2 or 3 seconds later. When we press a key and hold it, we usually see the chars appear in real-time. With 9 pics in the viewport, nothing happens until we release the key. Then all the chars appear at once.

With 12 or more pics in the viewport it's impossible to type anything except in slow motion. When typing in normal speed you always must do a break to see the chars appear, so you cannot read anything while you type.

With libreoffice-gtk2 it work's fine, but for some reason libreoffice always crashes after some minutes with libreoffice-gtk2 on SLE 15.

With the QT interface, i.e., neither libreoffice-gtk3 nor -gtk2 installed, typing works fine even with all 15 pics visible.

We really would like to use the GTK3 interface, e.g. due to the features of the save/load dialog (tab-completion), but then libreoffice is impossible to use with any document containing a few pics on a page.

Actual Results:
Slow scroll speed

Expected Results:
Normal speed


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 Telesto 2019-02-04 21:03:36 UTC
@Frank Steiner
I created a new report for this issue. A sample file would be nice :-)

@Buovjaga
FYI
Comment 2 Frank Steiner 2019-02-05 07:25:26 UTC
Created attachment 148887 [details]
Testfile for the picture bug
Comment 3 Frank Steiner 2019-02-05 07:25:51 UTC
Created attachment 148888 [details]
picture used in the test file
Comment 4 Frank Steiner 2019-02-05 07:26:25 UTC
Here you are! I hope this helps!
Comment 5 Buovjaga 2019-02-05 12:21:34 UTC
Created attachment 148904 [details]
Callgrind output from master

Took it only of typing.

Arch Linux 64-bit
Version: 6.3.0.0.alpha0+
Build ID: 5408f0731b9cd8be0e1b7aa5145b825337baad84
CPU threads: 8; OS: Linux 4.20; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 5 February 2019
Comment 6 Caolán McNamara 2019-02-06 08:57:03 UTC
This is much worse under X than wayland. As far as I can see the same amount of work is done under gtk2 as gtk3, except in gtk3 we have to wait until the draw signal arrives, at idle time, to blit our results to the screen. But the bitmap scaling is so slow that there isn't an idle between keystrokes. Under gtk2 we don't have to wait for idle, so screen updates get through
Comment 7 Telesto 2019-02-06 09:46:51 UTC
(In reply to Caolán McNamara from comment #6)
> This is much worse under X than wayland. As far as I can see the same amount
> of work is done under gtk2 as gtk3, except in gtk3 we have to wait until the
> draw signal arrives, at idle time, to blit our results to the screen. But
> the bitmap scaling is so slow that there isn't an idle between keystrokes.
> Under gtk2 we don't have to wait for idle, so screen updates get through

Related to: "bitmap scaling is so slow"
* performance issues started to appear after unified Graphic processing to use GraphicPrimitive2D (meta bug 116109)
* Some old DEV-notes about scaling/ scaling methods & performance bug 86675 c15 & c16 ...
Comment 8 Caolán McNamara 2019-02-06 14:07:00 UTC
https://gerrit.libreoffice.org/#/c/67459/ makes a big difference for me to make this test case usable
Comment 9 Buovjaga 2019-02-06 15:22:52 UTC
(In reply to Caolán McNamara from comment #8)
> https://gerrit.libreoffice.org/#/c/67459/ makes a big difference for me to
> make this test case usable

I built with it and confirm.
Comment 10 Commit Notification 2019-02-07 10:32:11 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/9f3926df5c2828ad3e8cfce2b4444b1c84352cf4%5E%21

tdf#123165 cache recently scaled bitmaps for reuse

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Caolán McNamara 2019-02-07 10:58:13 UTC
The fundamental problem is the same as most of the rest of the bugs associated with bug 116109, constant redraw of those images during typing and their constant rescaling.

With this hacky scaled-image cache some of those related bugs might also appear to go away or become acceptable in speed. I'm sure there's a better way to go about this and then maybe this can be thrown away in favour of some better overall fix when and if that shows up.

I'll call this "fixed", given comment #9, backport to 6-2 in gerrit
Comment 12 Commit Notification 2019-02-07 18:11:27 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-6-2":

https://git.libreoffice.org/core/+/0012f765304a9587d77ccb54bbeeef4e332e5d92%5E%21

tdf#123165 cache recently scaled bitmaps for reuse

It will be available in 6.2.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Frank Steiner 2019-03-01 07:44:02 UTC
I was just able to test the opensuse RPMs that were built with this patch. It's perfect! Thank you very very much for fixing this so quickly :-D