Bug 78529 - Editing very slow with big picture on page
Summary: Editing very slow with big picture on page
Status: RESOLVED DUPLICATE of bug 80659
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, perf, regression
Depends on:
Blocks:
 
Reported: 2014-05-10 14:23 UTC by lapont
Modified: 2016-09-30 08:00 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
orgel.odt document width 1.4 MB picture. (1.43 MB, application/vnd.oasis.opendocument.text)
2014-05-11 11:59 UTC, lapont
Details
sample odt file with some images - try to scroll down and up, it's so slow... (59.97 KB, application/vnd.oasis.opendocument.text)
2014-07-03 18:14 UTC, crysman
Details
40kb svg slows down writer (49.26 KB, application/vnd.oasis.opendocument.text)
2014-11-02 04:45 UTC, CiberSheep
Details
svg with pattern slows down writer (22.24 KB, application/vnd.oasis.opendocument.text)
2014-11-06 15:39 UTC, CiberSheep
Details
regular stroke svg no problem (22.24 KB, application/vnd.oasis.opendocument.text)
2014-11-06 15:41 UTC, CiberSheep
Details
gif 300dpi grayscale slowsdown writer (140.67 KB, application/vnd.oasis.opendocument.text)
2014-11-06 15:43 UTC, CiberSheep
Details
gif 300dpi 1bit no problem (91.07 KB, application/vnd.oasis.opendocument.text)
2014-11-06 15:45 UTC, CiberSheep
Details
108k PNG that causes Lagginess (128.29 KB, application/vnd.oasis.opendocument.text)
2015-08-18 21:31 UTC, dvcroft
Details
4MB png that does NOT lag on our fast machines (4.21 MB, application/vnd.oasis.opendocument.text)
2015-08-18 21:36 UTC, dvcroft
Details

Note You need to log in before you can comment on or make changes to this bug.
Description lapont 2014-05-10 14:23:50 UTC
Editing very slow if there is a big graphics picture on page.
Make a new writer document 
Add a picture bigger then 750kB. Scale picture so there is free space on page.
Try to add some text on the free space.
On my system there is a lag on 2 to 3 secs from key is pressed and till the character shows up.
Add a manual page break. No lag when editing page 2
My computer is Asus eeeBox whith Intel Atom, so not very powerfull. On a more powerfull hardware you could try with a bigger picture.
Comment 1 retired 2014-05-11 10:03:24 UTC
Please provide a test file and after that set the bug back to unconfirmed. Thanks.
Comment 2 lapont 2014-05-11 11:59:16 UTC
Created attachment 98840 [details]
orgel.odt document width 1.4 MB picture.

Typing is slow when editing this document i LibreOffice 4.2 Writer
Comment 3 Yousuf Philips (jay) (retired) 2014-05-31 03:22:01 UTC
Confirmed in Linux Mint with LibO 4.2.4, 4.2.6 and 4.3 beta. Its 4.1.6 and below are not effected by this. This effects Windows 7 as well.
Comment 4 Maris Nartiss 2014-06-08 16:45:10 UTC
Same on ~AMD64 Gentoo with LO 4.2.4.2

Looks like a duplicate of Bug 60425
Comment 5 lapont 2014-06-09 13:20:42 UTC
This is a new bug that only affects LO versions 4.2.x and over.
It is certanly not a dublicate of bug 60425!!!!
Comment 6 Michael Stahl (CIB) 2014-06-13 19:14:36 UTC
bibisect range:
3c01203ea657b9a3538f9956591b3d4da5fce6e7..0aa9ced531b8d85ad067c1d156a9708eea628d78

ah... of course it's commit 
2e5167528f7566dd9b000e50fc1610b7bf99132a yet again
Comment 7 Michael Stahl (CIB) 2014-06-30 15:01:34 UTC
*** Bug 80659 has been marked as a duplicate of this bug. ***
Comment 8 Michael Stahl (CIB) 2014-06-30 18:28:35 UTC Comment hidden (obsolete)
Comment 9 crysman 2014-07-03 16:26:23 UTC
The same here (Xubuntu 14.4). I have an Intel i5 processor, and it is ridiculously slow :( I am not aware now if previous versions had the same bug (I had been using OpenOffice back then), but I think that not.

I am also confirming the same behavior on Windows XP platform.

This needs to be fixed, it's a pain and shame - we just let MS Word users to laugh :(
Comment 10 crysman 2014-07-03 16:44:27 UTC
Actually, Calc has got the same problem. It is not only Writer.
Comment 11 Yousuf Philips (jay) (retired) 2014-07-03 16:56:03 UTC
Hi crysman@seznam.cz,

Can you provide a sample document that shows this same behaviour.
Comment 12 crysman 2014-07-03 18:14:24 UTC
Created attachment 102211 [details]
sample odt file with some images - try to scroll down and up, it's so slow...

I've included the sample file.
Comment 13 Yousuf Philips (jay) (retired) 2014-07-03 22:08:31 UTC
Hi crysman@seznam.cz,

Thanks for the sample. I also found calc slow in scrolling when there is a chart on the page with attachment 102219 [details].
Comment 14 Kevin Suo 2014-07-07 10:22:07 UTC
I do not reproduce this with verion 4.3.0.2, win xp sp3.
Scrolling and editing is very fast without delay.

My PC is just 2G RAM, 3Ghz CPU.
Comment 15 crysman 2014-07-07 18:27:47 UTC
@Kevin Suo:
Then it is maybe (?) problem of the 4.2.x series, as wrote @lp@lapont.dk

I've made these tests:

1) on my laptop (4GB RAM, Intel Core i5)
LibreOffice 4.2.4.2 420m0(Build:2)
Linux crysman-U36SD 3.13.0-29-generic #53-Ubuntu SMP Wed Jun 4 21:00:20 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

->SLOW!


2) on another desktop (960MB RAM, Pentium D 2.66)
LibreOffice 4.2.3.3
Windows XP SP3

->SLOW!



In both cases I've inserted a 1600x1453px jpeg image [http://4.bp.blogspot.com/-X0hxdtQm43E/UJ1aRHgW-pI/AAAAAAAAFJY/GNu3kXJMtOk/s1600/Analog-clock.jpg], resized it to some 5cm, made 4 copies of that and distributed on page... At this point it has became incredibly SLOW... :(
Comment 16 crysman 2014-07-07 18:41:30 UTC
PS: I've tried similar test on the 2) machine in MS Word (ver. 2003) to compare. It is slow, too, but in an acceptable way. Everything is significantly faster than in LibreOffice, although not fluent.
Comment 17 Kevin Suo 2014-07-25 14:25:02 UTC
Please ignore my comment 14.

I confirm this issue with master~2014-07-22_02.33.57_LibreOfficeDev_4.4.0.0.alpha0/

* Edit is slow when there is picture;
* Scrolling is also slow;
* When delete the picture, it becomes fast;

This may be a duplicated or related to "Bug 80659 - VIEWING: Scrolling becomes slow when pictures appear", as in version 4.1.0 beta 1 editing is fast and scrolling is also fast but in the newer version editing and scrolling both slow.

So I guess the slow editing is caused by the slow scrolling issue
Comment 18 Garri 2014-09-07 10:13:23 UTC
I can confirm that 2e5167528f7566dd9b000e50fc1610b7bf99132a is a first bad commit related to the regression in 4.2.x branch. Tested using sample attachment https://bugs.freedesktop.org/attachment.cgi?id=105237.

The built LO at point of commit 57c54792781cc9befe3a65a97b37fa85f89da0ae really was not affected by the bug as I reported earlier in bug 80659. (I incorrectly tested build using another sample and killed 2 days trying to find first bad commit :))
Comment 19 Garri 2014-09-08 06:28:51 UTC
Excuse me, what is required to move status to CONFIRMED? Thanks!
Comment 20 Yousuf Philips (jay) (retired) 2014-09-08 11:44:29 UTC
The confirmed status is set as NEW. :)
Comment 21 Garri 2014-09-14 18:15:33 UTC
(In reply to comment #20)
> The confirmed status is set as NEW. :)

Thank you, Jay! Sorry for the stupid question. :)
Comment 22 Björn Michaelsen 2014-10-16 14:59:10 UTC Comment hidden (obsolete)
Comment 23 CiberSheep 2014-11-02 04:45:07 UTC
Created attachment 108785 [details]
40kb svg slows down writer
Comment 24 CiberSheep 2014-11-02 04:45:48 UTC
Comment on attachment 108785 [details]
40kb svg slows down writer

Confimed in 4.3.3.3 in Ubuntu 14.04 64bits. 
I had inserted an greyscale image A4@300dpi and it slows down. When I convert the image to 1bit B/N png @ 200 dpi works well.

Some SVG seem to give a similar problem. From inkscape, optimized...


Intel® 965GM 
Intel® Pentium(R) Dual CPU T2310 @ 1.46GHz × 2
Comment 25 CiberSheep 2014-11-06 15:39:49 UTC
Created attachment 109046 [details]
svg with pattern slows down writer

I have found that:
 when inserting a svg with a pattern in a line writer slowsdown
Comment 26 CiberSheep 2014-11-06 15:41:20 UTC
Created attachment 109047 [details]
regular stroke svg no problem

Smae stroke as previous attachment but without the pattern (regular stroke style) gives no problem when scrolling
Comment 27 CiberSheep 2014-11-06 15:43:46 UTC
Created attachment 109048 [details]
gif 300dpi grayscale slowsdown writer

Also, I tested writer with two gifs. One grayscale indexed, that slowsdown writer (this attachment) and a 1bit indexed B/W that gives no problmes (see next attachment)
Comment 28 CiberSheep 2014-11-06 15:45:24 UTC
Created attachment 109049 [details]
gif 300dpi 1bit no problem

This gif gives no problem (a bit less quality image). Writer shows it regular speed
Comment 29 dvcroft 2015-08-18 21:31:00 UTC
Created attachment 118007 [details]
108k PNG that causes Lagginess

We are using very fast machines (i7-4770 CPU @ 3.40GHz with 8GB RAM) and LibreOffice 4.3.7.2 on Linux (OpenSuse 13.2).

When we open the attached document, and hold down the backspace key at the end of the text, Libre does not keep up with the deletes, and the deletes continue after releasing the backspace key.

Note that the embedded image is only 108k.
Comment 30 dvcroft 2015-08-18 21:36:13 UTC
Created attachment 118008 [details]
4MB png that does NOT lag on our fast machines

The bug is not caused solely by the filesize (at least for us). Using the same fast hardware and software versions, the attached document does not cause a lag. Repeating a backspace libre keeps up fine.

Note that the image in this document has the same resolution as the last one, and it is less compressible, so the file size is 4Mb as opposed to 108k.
Comment 31 dvcroft 2015-08-18 22:16:02 UTC
I have also tested my lag and no lag documents in 4.4.5 and 5.0.0.5.

I have the same results in 4.4.5 as in 4.2. 

In version 5.0.0.0 backspace no longer continues after releasing, but that is because a fix was added to libre that throws away excess repeat keys that are not being serviced.

In 4.4 my machine CPU load gets over 20% doing repeat backspace on the lag document and it is only 4% on the no lag document.

In 5.0 the cpu load goes over 40% doing repeat backspace on the lag document.
Comment 32 Robinson Tryon (qubit) 2015-12-10 09:46:22 UTC Comment hidden (obsolete)
Comment 33 Noel Grandin 2015-12-17 07:18:01 UTC
It's ending up in OutputDevice::ScaleBitmap on every keystroke.
According to alg, this should not be the case - it should be using hardware scaling.
But I can't follow the vcl paths down below OutputDevice::DrawTransformedBitmapEx, just too confusing.
Comment 34 Michael Meeks 2015-12-18 09:38:33 UTC
Yes; its reasonably well known that our rendering does not cache scaled versions of bitmaps; or sub-divided polygons or whatever - but re-does the work each time things are rendered; (in some cases for each mouse-event for hit-testing etc.).

Armin is the expert wrt. advice on this I think.
Comment 35 Armin Le Grand 2016-08-26 16:12:57 UTC
When it's about bitmap scaling I suppose it's linux only (win and mac do this in hw). Can someone confirm this (and change the 'Hardware' fields accordingly)?
Comment 36 Aron Budea 2016-08-29 03:38:36 UTC
In Windows 7 testing with a fairly recent master build (with enable-symbols), the situation has improved a lot. I only experienced laggy scrolling with the following attachments, and the source of that lagginess can be categorized as follows (based on a bit of simple profiling with Very Sleepy):

1. GdipCreateSolidFill call takes up significant time

-"sample odt file with some images - try to scroll down and up, it's so slow..."
-"4MB png that does NOT lag on our fast machines"

2. Bitmap::ImplConvertDown and `anonymous namespace'::scalePallete8bit2 calls & callees eat up a lot of time

-"gif 300dpi grayscale slowsdown writer"


Typing is also slow, except in "sample odt file with some images - try to scroll down and up, it's so slow...".
No lag with OpenGL rendering.
Comment 37 Xisco Faulí 2016-09-26 15:03:14 UTC
Adding Cc: to Armin Le Grand
Comment 38 Armin Le Grand 2016-09-29 15:16:23 UTC
Probably double to bug 80659
Comment 39 Michael Meeks 2016-09-30 08:00:35 UTC
Marking duplicate then - in all probability this is indeed the problem.
Thanks !

*** This bug has been marked as a duplicate of bug 80659 ***