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:
@Frank Steiner I created a new report for this issue. A sample file would be nice :-) @Buovjaga FYI
Created attachment 148887 [details] Testfile for the picture bug
Created attachment 148888 [details] picture used in the test file
Here you are! I hope this helps!
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
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
(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 ...
https://gerrit.libreoffice.org/#/c/67459/ makes a big difference for me to make this test case usable
(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.
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.
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
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.
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