Created attachment 129696 [details]
odt file with images and mMendeley references

I can confirm slow scrolling using the attached sample in 5.2.3.3 and 5.3beta2 / Windows 7, both with OpenGL enabled and disabled.

(In reply to m.a.riosv from comment #3)
> Please test if you have at least 64 on Menu/Tools/LibreOffice/Memory - Image
> Cache size - Use for LibreOffice.
> Actual defaults
> Use for LibreOffice 190
> Memory per object 12
> Remove from memory after 00:10
> Number of objects 20

The default in the computer I am now (i7 8GB RAM 256 SSD) with LO 5.2.3.2 was 64/12/00:10/20. I increased it to 320/64... (and restarted LO) with no effect.

Looks like the issue is with the images 9 and 10, they are complex svg files.

In any case works much better with 5.1 and with 5.2.

5.0 is EOL, please test with a new version.

(In reply to m.a.riosv from comment #6)
> Looks like the issue is with the images 9 and 10, they are complex svg files.
> 
> In any case works much better with 5.1 and with 5.2.
> 
> 5.0 is EOL, please test with a new version.

@m.a.riosv, Those two images are not the only problem. 

It is true the root of the problem seems to be related with images in either:

1. Complexity (as the 120/250KB .svg images you tak about): see 1_SVG.odt
2. Size (a few 1MB/3MB pics): see 2_Size.odt
3. Number (a big number of <500KB pics): see 3_Number.odt

And not (as I mistakenly thought), Mendeley references: see 4_References.odt

I have no technical expertise whatsoever, but it seems related to the number of KB that can show/work with at the same time... For example, the smaller the zoom, the worst the problem becomes (50% zoom is bad enough for this files). Or the more files you open, the worst it becomes (even if half the computer's RAM is available).

I am focusing here in the Writer problem, but in Impress, working with big files with lots of images (copy pasting a few slides) is very painful. I guess it might be the same root cause in both...

Created attachment 129718 [details]
1. Big SVG pics

Created attachment 129719 [details]
2. Big jpg images

Created attachment 129720 [details]
3. Big number of small pics

Created attachment 129721 [details]
4. Lots of references - OK

(In reply to m.a.riosv from comment #6)
> Looks like the issue is with the images 9 and 10, they are complex svg files.
> 
> In any case works much better with 5.1 and with 5.2.
> 
> 5.0 is EOL, please test with a new version.

BTW, I tested with 5.0, 5.2 and 5.3 in Ubuntu, and with 5.2 in Windows. I entered 5.0 in the bug report, because the problem "starts" at least there.

About attachment 1 with svg images. 

Only at the first scroll bottom quite slow:
Version: 5.4.0.0.alpha0+
Build ID: b5cc02ee1b582a6f19e23eb2f1deb1392b3974c0
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-12-15_02:27:38
Locale: nl-NL (nl_NL); Calc: CL

the same can be said about
Versie: 5.3.0.0.beta1  (x64)
Build ID: 690f553ecb3efd19143acbf01f3af4e289e94536
CPU Threads: 4; Versie besturingssysteem:Windows 6.19; UI Render: standaard; Layout Engine: new; 
Locale: nl-NL (nl_NL); Calc: CL

always a bit choppy in:
Versie: 5.2.4.1 
Build ID: 9b50003582f07ac674d6451e411e9b77cccd2b22
CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; 
Locale: nl-NL (nl_NL); Calc: CL

same in:
LibreOffice 3.5.7.2 
Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b


I have tested attachment 2 and 3 on a Windows system. 

It's quite OK in
Version: 5.4.0.0.alpha0+
Build ID: b5cc02ee1b582a6f19e23eb2f1deb1392b3974c0
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-12-15_02:27:38
Locale: nl-NL (nl_NL); Calc: CL

and in:
Versie: 5.3.0.0.beta1  (x64)
Build ID: 690f553ecb3efd19143acbf01f3af4e289e94536
CPU Threads: 4; Versie besturingssysteem:Windows 6.19; UI Render: standaard; Layout Engine: new; 
Locale: nl-NL (nl_NL); Calc: CL

Not so in:
Versie: 5.2.4.1 
Build ID: 9b50003582f07ac674d6451e411e9b77cccd2b22
CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; 
Locale: nl-NL (nl_NL); Calc: CL

The scrolling experience is at it's best in:
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4

(In reply to Telesto from comment #13)
> About attachment 1 with svg images. 
> 
> Only at the first scroll bottom quite slow:
> Version: 5.4.0.0.alpha0+
> Build ID: b5cc02ee1b582a6f19e23eb2f1deb1392b3974c0
> CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
> TinderBox: Win-x86@42, Branch:master, Time: 2016-12-15_02:27:38
> Locale: nl-NL (nl_NL); Calc: CL
> 
> the same can be said about
> Versie: 5.3.0.0.beta1  (x64)
> Build ID: 690f553ecb3efd19143acbf01f3af4e289e94536
> CPU Threads: 4; Versie besturingssysteem:Windows 6.19; UI Render: standaard;
> Layout Engine: new; 
> Locale: nl-NL (nl_NL); Calc: CL
> 
> always a bit choppy in:
> Versie: 5.2.4.1 
> Build ID: 9b50003582f07ac674d6451e411e9b77cccd2b22
> CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; 
> Locale: nl-NL (nl_NL); Calc: CL
> 
> same in:
> LibreOffice 3.5.7.2 
> Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
> 
> 
> I have tested attachment 2 and 3 on a Windows system. 
> 
> It's quite OK in
> Version: 5.4.0.0.alpha0+
> Build ID: b5cc02ee1b582a6f19e23eb2f1deb1392b3974c0
> CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
> TinderBox: Win-x86@42, Branch:master, Time: 2016-12-15_02:27:38
> Locale: nl-NL (nl_NL); Calc: CL
> 
> and in:
> Versie: 5.3.0.0.beta1  (x64)
> Build ID: 690f553ecb3efd19143acbf01f3af4e289e94536
> CPU Threads: 4; Versie besturingssysteem:Windows 6.19; UI Render: standaard;
> Layout Engine: new; 
> Locale: nl-NL (nl_NL); Calc: CL
> 
> Not so in:
> Versie: 5.2.4.1 
> Build ID: 9b50003582f07ac674d6451e411e9b77cccd2b22
> CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; 
> Locale: nl-NL (nl_NL); Calc: CL
> 
> The scrolling experience is at it's best in:
> LibreOffice 3.3.0 
> OOO330m19 (Build:6)
> tag libreoffice-3.3.0.4

Thanks a lot for the thorough testing. Have you notice how it is zoom level dependent?

Another important thing is that those are basic sample files. Increasing the number of images or their size makes the problem worst.

Created attachment 129723 [details]
Screencast scrolling LO5400

Indeed, its getting worse after adding images and changing zoom. Adding a small screencast.
Version: 5.4.0.0.alpha0+
Build ID: b5cc02ee1b582a6f19e23eb2f1deb1392b3974c0
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-12-15_02:27:38
Locale: nl-NL (nl_NL); Calc: CL

FWIW, the importance of this bug is major to critical for my group of reference (academics). I am not changing it back to critical myself, but really hope you guys could increase the importance.

In brief, the bug makes LO unusable for any serious work (e.g. preparing a presentation for a lecture) or working in a medium-big report (those necessarily include a lot of images), etc.

Just as an anecdote, one of my colleagues to which I "convinced" to use almost exclusively LO is now pondering if it is worth it, as in the last few days he had to switch to MSOffice for a presentation and we also had to switch for the report I originally attached in this report.

I think the issue is in relation with svg images, compresing those images they are converted to jpeg, using right-click/compress, for me help with the fluidility specially scrolling on those slow images.

I set up as new.

(In reply to m.a.riosv from comment #17)
> I think the issue is in relation with svg images, compresing those images
> they are converted to jpeg, using right-click/compress, for me help with the
> fluidility specially scrolling on those slow images.
> 
> I set up as new.

When you compress the .svg images, they become ~80kB jpg, so the problem is solved, probably because you get rid of the big/complex images, not because it was with .svg specifically. At least, that is my impression.  

Also, if you scroll up and down repeatedly at 50% zoom in the "2. Big jpg images" file, you will also notice the issue, and there are no .svg images there. And if you add more big pics (>1MB) to that file (.jpg, .png...), and/or decrease the zoom level, the problem becomes worst.

Each issue (section break, paragraph break, text box, picture...) should be reported separately, only after a search for already reported bugs, with clear issue in the title. 

1. Slow page scrolling when an SVG object is in view is already a known issue (bug 96880)
2. The JPG scrolling seems to be 'new'

Created attachment 130327 [details]
Writer document with 30 png figures and a lot of png equations

Created attachment 130328 [details]
test_fig_png+eqs_svg.odt - Writer document with 30 png figures and a lot of svg equations

Created attachment 130329 [details]
test_fig_jpg+eqs_jpg.odt - Writer file with 30 jpg figures and a lot of jpg equations

I'm also affected by this big performance issue, so I decided to report the tests I've done.

I've attached three test documents:

1. test_fig_png+eqs_png.odt is a Writer document with more than 30 png big figures and a lot of small png images (that are LaTeX equations created with the TexMaths extension). The document has 70 pages and is an anonymized version of a real document I'm working on for my company.

2. test_fig_png+eqs_svg.odt, same document with equations as svg images instead of png images

3. test_fig_jpg+eqs_jpg.odt, same document with all images converted to jpeg.


My hardware and system:
-----------------------

- HP workstation z820, with two Intel Xeon E5-2687W 0 @ 3.10GHz (16 cores, 32 threads), Nvidia Quadro K2000, 128 GB RAM

- Ubuntu 16.04.1 64 bits


Tested Libreoffice versions:
----------------------------

3.6.7, 4.4.7.2, 5.0.6.3, 5.1.6.2, 5.2.4.2, 5.3.0.1 and also Openoffice 4.1.3


Memory parameters in Libreoffice:
---------------------------------

Use for Libreoffice: 256 MB, Memory per object: 32 MB, Number of objects: 512


Observed scrolling performances:
--------------------------------

- versions 3.x, 4.x and Openoffice 4.x have (nearly) the same scrolling performances. Scrolling is rather smooth in single page view, with zoom factor > 50%. With smaller zoom factors, it becomes slow. In multipage view, with 6 pages per window, it becomes quite slow and it is hard to use this mode. There is no big difference between the three documents, but I think that svg images are indeed a little bit slower to scroll.

- all versions 5.x have (nearly) the same performances, however scrolling is noticeably slower than in 3.x and 4.x versions with the three documents. For the png and jpg documents, in single page view, with zoom factor > 50%, scrolling is rather smooth and usable but there is a noticeable lag. With smaller zoom factors or multipage view, scrolling becomes really slow, and it's very difficult to work in such modes.

For the document with svg images, scrolling is slow in single page view with zoom factor > 50%. There is a big lag and navigating through the document is painful. Working with smaller zoom factors or in multipage view is completely unusable: I have to wait for a bunch of seconds between each little move of the text...


Comparison with MS Office 2010:
-------------------------------

I've tested the scrolling speed with the three documents (after conversion to .doc in Libreoffice) in MS Office 2010, under a virtual machine (Windows 7 64 bits under Virtualbox 5.1.12) and I found that scrolling in Word 2010 is completely smooth in all view modes (100% zoom, smaller zoom factors, multipage view). There is no speed difference between the three documents.


Other observations:
-------------------

I've tested various combinations of the memory parameters in Libreoffice / Tools / Options / Memory, but I didn't see any influence of these parameters on the scrolling speed.

I also tried to use OpenGL rendering: in 3.x and 4.x versions, the UI is quite ugly and the scrolling speed is the same. In 5.x versions, Writer does not start when OpenGL rendering is selected.

 
To summarize:
-------------

1) Scrolling with svg images is slower in 5.x versions than in previous versions (probably due to the API change?). Its is very difficult to work with document that embed of lot of small svg images, or big svg images (as demonstrated by the other comments).

2) Scrolling with a lot of small png or jpg images is also slow, especially at small zoom factors or in multipage view.

Hi Roland,

Thanks for your detailed tests and report!

(In reply to Roland Baudin from comment #23)

> - HP workstation z820, with two Intel Xeon E5-2687W 0 @ 3.10GHz (16 cores,
> 32 threads), Nvidia Quadro K2000, 128 GB RAM

 (me a bit jealous ;) )

> - all versions 5.x have (nearly) the same performances, however scrolling is
> noticeably slower than in 3.x and 4.x versions with the three documents. For
> the png and jpg documents, in single page view, with zoom factor > 50%,
> scrolling is rather smooth and usable but there is a noticeable lag. With
> smaller zoom factors or multipage view, scrolling becomes really slow, and
> it's very difficult to work in such modes.

That sounds as a good reason to ask for bibisecting.
(OTOH, I have the impression that (a) developers is/are working on cleaning/rewriting image handling, so it could be a waste of time too. @caolán: could you give advise here please?)

its worth bisecting to find what changed to see if someone can point to an objectively reproducible point where performance changed.

Hi Roland,

How do you scroll? With the mouse or with the scrollbar? I see significant difference if I use the scrollbar or the mouse: smooth with the scrollbar and slow with the mouse.

Best regards. JBF

Possibly a duplicate of bug 80659.

I have serious (it's not workable) problems with performance too. Even relativly moderate complexity in drawings makes moving objects around nearly impossible. You have to wait for anything to happen for seconds.
Tested on machines with Core i5 or Core i7, 16 GB RAM, SSD storage. Windows + LibreOffice 32b current version, Linux + LibreOffice 64b Debian Stretch current version.

Created attachment 133327 [details]
Sample of some imported stencils

(In reply to Jean-Baptiste Faure from comment #26)
> Hi Roland,
> 
> How do you scroll? With the mouse or with the scrollbar? I see significant
> difference if I use the scrollbar or the mouse: smooth with the scrollbar
> and slow with the mouse.
> 
> Best regards. JBF

Same results with both methods: scrolling is painfully slow when there are many images in the document.

Any news on this very annoying bug?

There is a tender in relation with this matter.

https://blog.documentfoundation.org/blog/2017/05/02/tender-improve-image-handling-libreoffice-201705-01/

(In reply to Roland Baudin from comment #31)
> Any news on this very annoying bug?

you may help with bibisecting https://wiki.documentfoundation.org/QA/HowToBibisect

Created attachment 136239 [details]
Complex document with a lot of PNG and SVG images

I did some tests with a new document I wrote last year (complex document with a lot of PNG and SVG images). I compared the scrolling speed of LibreOffice 5.3.x and 5.4.x and I found some interesting results...

To measure the scrolling speed, I simply opened the file in Writer (with a fresh profile), set the zoom factor to 140% in single page view, and maintained the PageDown key pressed to scroll the entire document from the beginning to the end, and recorded the time it took.

Below, the test conditions:

- Hardware is HP workstation z820, with two Intel Xeon E5-2687W 0 @ 3.10GHz (16 cores, 32 threads), Nvidia Quadro K2000, 128 GB RAM

- Systems are Ubuntu Linux 16.04.3 LTS (Xenial Xerus) 64-bit and Windows 7 Professional 64 bits

- On Linux, LibreOffice versions are 5.3.6.1 and 5.4.1.2 (both 64 bits)

- On Windows, LibreOffice versions are 5.3.5.2 and 5.4.0.3 (both 32 bits)

- On Linux and Windows, I set the CPU frequency to its maximum (performance mode)


Here are the scrolling durations I obtained (I repeated the tests several times and these durations are consistent):

Linux
------

5.3.x => 57"
5.4.x => 10"


Windows
--------

5.3.x => 1'50"
5.4.x => 48"


As you can see, on Linux the scrolling speed was increased in LO 5.4.x by a factor of about 6, which is impressive! Now, I can work flawlesslly on such a complex document. As a matter of comparison, the scrolling duration measured on Windows 7 using Word 2010 is 16". So LO 5.4.x is faster than Word on Linux on this document!

However, on Windows, there is also a performance improvement in LO 5.4.x by a factor 2, but the scrolling speed is still by far too slow. Perhaps, it is related to the fact I tested using 32 bits LO on a 64 bits Windows? Unfortunately, I was not able to test a 64 bits LO on Windows due to some right limitations set by my company on this system.

So, the situation is now better than last year. However, I have to mention that scrolling a complex document in multi page view is still completely unusable, whatever the system and the LO versions...

I forgot to mention that on Windows, the scrolling duration is the same with or without OpenGL. On Linux, LO crashed when OpenGL was enabled.

More tests with a different hardware (custom PC with Intel Core i7 6700K @ 4 GHz - 4 cores - RAM 16 GB) and same systems (but with 64 bits LO on Windows):

Linux
------

5.3.x => 28"
5.4.x => 12"


Windows
--------

5.3.x => 58"
5.4.x => 27"

So this confirms that 5.4.x is faster. It is also confirmed that LO on Linux is faster than on Windows, with respect to scrolling.

On Windows, scrolling with OpenGL on this machine is a bit faster than without OpenGL. However, rendering of SVG images is ugly (bold blurry lines) and I expected some crashes. I'm a bit surprised to see that OpenGL is the default on Windows. This is really a weird choice!

just a note that sort of "general" bugs are basically unfixable due to vagueness of the target

Indeed, the reported problem is more a serious performance issue rather than a bug.

To reproduce the issue:
1. Open any of the attached files with Writer
2. Set the view mode to 'Multi-page view'
3. Set the zoom factor to 50%
4. Scroll the document

At least, it would be useful to understand why scrolling is much faster on Linux than on Windows?

Nice news! Does it mean that you fixed the issue?

(In reply to Roland Baudin from comment #41)
> Nice news! Does it mean that you fixed the issue?

Nope, only (tried) to find the problematic commit - change - which caused the slow down. But - sadly - the commit I identified is wrong. Reverted:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=ee36fc7add892690c95a969530ecdcfc1bc9decc

*** Bug 113347 has been marked as a duplicate of this bug. ***

(In reply to Telesto from comment #42)
> (In reply to Roland Baudin from comment #41)
> > Nice news! Does it mean that you fixed the issue?
> 
> Nope, only (tried) to find the problematic commit - change - which caused
> the slow down. But - sadly - the commit I identified is wrong. Reverted:
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=ee36fc7add892690c95a969530ecdcfc1bc9decc

OK, that's life...

Using STR of comment 35 seem to have done some good for Windows builds of master > 20171103, the patch has been pushed to 5.4.4.

http://cgit.freedesktop.org/libreoffice/core/commit/?id=11459949e920fab6074bab85e3e1a748e9aee1ee

Related: tdf#113347: properly check HRESULT value

Here are more tests on Linux, using recent versions of LibreOffice:


1. Test conditions
==================

- Hardware is HP workstation z820, with two Intel Xeon E5-2687W 0 @ 3.10GHz (16 cores, 32 threads), Nvidia Quadro K2000, 128 GB RAM

- CPU frequency set to its maximum (performance mode)

- Ubuntu Linux 16.04.3 LTS (Xenial Xerus) 64-bit

- LibreOffice versions 5.4.4.2 and 6.0.1.1 (both 64 bits)

- GTK2 (no OpenGL) and GTK3 rendering

- Nvidia driver 340

- document 'test_complex_document.odt' (attachment 136239 [details])

- zoom 140% on a 24" monitor (default when opening the document)

- fresh LibreOffice profile for each test


2. Results
==========

a. Scrolling the entire document with the page down key
--------------------------------------------------------

5.4.4.2 GTK2 => 10"
5.4.4.2 GTK3 => 12"

6.0.1.1 GTK2 => 10"
6.0.1.1 GTK3 => 12"


b. Scrolling some pages with the mouse wheel
--------------------------------------------

5.4.4.2 GTK2 => fast
5.4.4.2 GTK3 => fast

6.0.1.1 GTK2 => fast
6.0.1.1 GTK3 => slow (much slower than with GTK2)


c. Scrolling the entire document with the mouse
-----------------------------------------------

5.4.4.2 GTK2 => fast
5.4.4.2 GTK3 => a bit slower than with GTK2

6.0.1.1 GTK2 => fast
6.0.1.1 GTK3 => a bit slower than with GTK2


d. Smooth scrolling activated
-----------------------------

5.4.4.2 GTK2 => fast
5.4.4.2 GTK3 => very slow, completely unusable

6.0.1.1 GTK2 => fast
6.0.1.1 GTK3 => very slow, completely unusable


3. Summary
----------

Versions 5.4.4.2 and 6.0.1.1 are fast with GTK2 rendering, whatever the scrolling method.
There are several issues with GTK3: keyboard scrolling is slower (both versions), mouse wheel scrolling is much slower (6.0.0.1) and mouse scrolling is slower (both versions). Also, smooth scrolling is completely unusable with GTK3.

(In reply to Roland Baudin from comment #46)
Might be relevant: http://nabble.documentfoundation.org/Why-does-the-GTK3-vcl-sal-plugin-default-to-SvpSalGraphics-software-rendering-td4232928.html

I haven't done any specific tests but I can confirm that scrolling documents which contain images is often very sluggish compared to Microsoft Word.

Intel Core i5-520M
4GB RAM
Intel HD Graphics integrated GPU
OpenGL usually off in Libreoffice

I have same problem when scrolling in libreoffice writer. I have tested the situation from 6.0 to 6.2 alpha preview version.
They all behave the same. In my situatuion, large pictures may not be the only cause. Also scrolling though 
complex tables is significantly slow . Changing from gtk3 to gtk2 should improve a little bit but still unacceptable. 
For each pagedown or up, almost 10 seconds is required. Continuously using the mouse's scroll wheel will freeze the screen 
for a long time. This makes the software almost useless. The size of my testing file is 5.2M with 16 pages.

Now i have to downgrade to libreoffice 5.4.7 where no such bug. Hope the problem can be solved very soon.

No similar problem found in calc or draw.

_______________
i7-4771 16M Ram 
GTX 650ti with nvidia 410 driver
Kde Neon 18.04
kubuntu 18.10
Ubuntu Budgie 18.10

(In reply to Samson Yeung from comment #49)
Please file a new bug report for your problem and add a sample file (if possible)

This bug is probably unrelated, because it's reproducible even with versions before LibreOffice 5.4 (see comment 0)

Thanks

I don't know why you say it is 2 different bugs. My description is consistent with e.g. comment 35.
Firstly, what i claimed is that the bug can be found in all version 6.
Secondly, Version 5.4.7 perform normally.
I haven't made any test for version 3 to version 5.3 which have been found buggy in other comments.
Deduced and summerized from all the comments, version 5.4 should be affected least.
The bug in question, namely, slow scrolling (mouse wheel or page up/down or scrollbar) in odt editing.
Am i get it right.
I have a sample file.But it is all in tradtional chinese. Maybe you'll find difficult to use.

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.

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.

This performance issue report is now two years old and nothing has improved.

Worse, I've read that the Libreoffice team will remove the gtk2 interface (the fastest and more stable one)!

The gtk3 interface is still buggy and slow, that's a pity...

Ok folks, this report has run its course and needs to be chopped up to any useful bits left.

Let's recap:
- Frank's issue from comment 52 is now bug 123165
- Roland's issues a-c from comment 46 seems non-existent in my tests
- Issue d from comment 46, Smooth scrolling + PgDn looks like a real problem with GTK3. I will open a new report for it and CC Roland. I will do a callgrind trace of it.
- Samson needs to create a new report with his example file for his problem from comment 49
- In comment 27, bug 80659 was suspected to be a duplicate of the immediately preceding issues mentioned by Roland and has now been confirmed to be gone by 3 people
- For comment 28 and 29, I remember there already being a separate report
- For Gorka's issues up to comment 18, we need to determine what is actionable and create new reports accordingly. Telesto: can you help with this? Slow page scrolling with SVGs in view is bug 83426, what about the others?
I confirmed with attachment 129696 [details] that scrolling with 8 pages in view is still sluggish.

Let this be a lesson to all: don't bring your pet bugs to existing reports. It will create a huge and painful mess.

Tests done on
Arch Linux 64-bit
Version: 6.3.0.0.alpha0+
Build ID: 8fbad2f600cd3ab81e7c1da0e4a2a71ebcac0553
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 31 January 2019

I did the same a-d tests of comment 46 with the new (beta?) 6.2.0.3 release on Linux and the same hardware and I obtained the same results (same timings and same issue with smooth scrolling enabled) for the GTK3 backend.

As I said before, scrolling an image is still a bit slow. If the document has many images, this is an issue when scrolling many times the document back and forth...

I couldn't test the GTK2 with LibreOffice 6.2.0.3. I don't even know if this backend is still available with this version?

(In reply to Roland Baudin from comment #55)
> I did the same a-d tests of comment 46 with the new (beta?) 6.2.0.3 release
> on Linux and the same hardware and I obtained the same results (same timings
> and same issue with smooth scrolling enabled) for the GTK3 backend.
> 
> As I said before, scrolling an image is still a bit slow. If the document
> has many images, this is an issue when scrolling many times the document
> back and forth...
> 
> I couldn't test the GTK2 with LibreOffice 6.2.0.3. I don't even know if this
> backend is still available with this version?

Launch from the command line with
SAL_USE_VCLPLUGIN=gtk libreoffice

> Launch from the command line with
> SAL_USE_VCLPLUGIN=gtk libreoffice

Oh yes, I remember this way now, thanks!

So I did again the a-d tests using the GTK2 backend and I got the same results as in comment 46.

As I noticed in comment 46, I see two issues with the GTK3 backend:

- scrolling the document with smooth scrolling activated is unusable, as you also noticed (and you filled a specific bug report, thanks)

- scrolling some pages with the mouse wheel is painfully slow. To see that, with the GTK3 backend, open "text_complex_document.odt", then go to page 104 and scroll up and down with the mouse wheel. Then do the same with the GTK2 backend and you should see a huge difference. Perhaps, this problem is related to the smooth scrolling bug?

(In reply to Roland Baudin from comment #57)
> > Launch from the command line with
> > SAL_USE_VCLPLUGIN=gtk libreoffice
> 
> Oh yes, I remember this way now, thanks!
> 
> So I did again the a-d tests using the GTK2 backend and I got the same
> results as in comment 46.
> 
> As I noticed in comment 46, I see two issues with the GTK3 backend:
> 
> - scrolling the document with smooth scrolling activated is unusable, as you
> also noticed (and you filled a specific bug report, thanks)
> 
> - scrolling some pages with the mouse wheel is painfully slow. To see that,
> with the GTK3 backend, open "text_complex_document.odt", then go to page 104
> and scroll up and down with the mouse wheel. Then do the same with the GTK2
> backend and you should see a huge difference. Perhaps, this problem is
> related to the smooth scrolling bug?

I have no slowness when mouse wheel scrolling up and down around pg 104 with GTK3, even with Smooth scroll activated. Maybe a more recent version has fixed the slowness. This would explain, why I get different results for a-c tests of comment 46.

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

> I have no slowness when mouse wheel scrolling up and down around pg 104 with GTK3, even with Smooth scroll activated. Maybe a more recent version has fixed the slowness. This would explain, why I get different results for a-c tests of comment 46.

I see the slowness with LO 6.2.0.3 in Ubuntu 18.04. I think this is the latest version, am I correct?

(In reply to Roland Baudin from comment #59)
> > I have no slowness when mouse wheel scrolling up and down around pg 104 with GTK3, even with Smooth scroll activated. Maybe a more recent version has fixed the slowness. This would explain, why I get different results for a-c tests of comment 46.
> 
> I see the slowness with LO 6.2.0.3 in Ubuntu 18.04. I think this is the
> latest version, am I correct?

Ok, maybe there is some difference in our systems. Do create a new report for the issue.

System is 10 core (20 threads) i9 running at 3.5Ghz, 62GB of ram, RTX2080 graphics, Ubuntu Groovy (same problems before upgrade to Groovy)

A simple Draw document, about 7" x 7", grid set to 0.1" x 4 divisions.

When the grid is visible it takes about 3 to 5 seconds to zoom in/out using the mouse wheel.

Grabbing and moving multiple objects is also very slow.

Hardware acceleration doesn't seem to make any difference.

Dual Display port 4K@60Hz video monitors

(In reply to Wilbur Harvey from comment #61)
> System is 10 core (20 threads) i9 running at 3.5Ghz, 62GB of ram, RTX2080
> graphics, Ubuntu Groovy (same problems before upgrade to Groovy)
> 
> A simple Draw document, about 7" x 7", grid set to 0.1" x 4 divisions.
> 
> When the grid is visible it takes about 3 to 5 seconds to zoom in/out using
> the mouse wheel.
> 
> Grabbing and moving multiple objects is also very slow.
> 
> Hardware acceleration doesn't seem to make any difference.
> 
> Dual Display port 4K@60Hz video monitors

Please create a new report for your issue.