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.
Please provide a test file and after that set the bug back to unconfirmed. Thanks.
Created attachment 98840 [details] orgel.odt document width 1.4 MB picture. Typing is slow when editing this document i LibreOffice 4.2 Writer
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.
Same on ~AMD64 Gentoo with LO 4.2.4.2 Looks like a duplicate of Bug 60425
This is a new bug that only affects LO versions 4.2.x and over. It is certanly not a dublicate of bug 60425!!!!
bibisect range: 3c01203ea657b9a3538f9956591b3d4da5fce6e7..0aa9ced531b8d85ad067c1d156a9708eea628d78 ah... of course it's commit 2e5167528f7566dd9b000e50fc1610b7bf99132a yet again
*** Bug 80659 has been marked as a duplicate of this bug. ***
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 :(
Actually, Calc has got the same problem. It is not only Writer.
Hi crysman@seznam.cz, Can you provide a sample document that shows this same behaviour.
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.
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].
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.
@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... :(
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.
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
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 :))
Excuse me, what is required to move status to CONFIRMED? Thanks!
The confirmed status is set as NEW. :)
(In reply to comment #20) > The confirmed status is set as NEW. :) Thank you, Jay! Sorry for the stupid question. :)
(This is an automated message.) It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.) Thus setting keyword "bisected".
Created attachment 108785 [details] 40kb svg slows down writer
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
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
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
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)
Created attachment 109049 [details] gif 300dpi 1bit no problem This gif gives no problem (a bit less quality image). Writer shows it regular speed
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.
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.
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.
Migrating Whiteboard tags to Keywords: (bibisected, perf)
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.
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.
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)?
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.
Adding Cc: to Armin Le Grand
Probably double to bug 80659
Marking duplicate then - in all probability this is indeed the problem. Thanks ! *** This bug has been marked as a duplicate of bug 80659 ***