Created attachment 112618 [details] Sample document helps to set up for replicating the issue with slow rendering We have been experiencing a bizarre issue with LibreOffice for many versions now. It happens with writer documents that contain a background image and a text frame on top. Under Linux, at certain viewing zoom levels and certain scroll positions, screen rendering of this type of document can be very slow, resulting in LO being unable to keep up with displaying letters in “real time” while typing. It also slows down rapid vertical up/down scrolling. This is much more noticeable on thin clients and remote Xservers (where Xorg and LO running on different machines across a network... in our case 100base Ethernet) and slower computers. The exact zoom level at which the problem starts to appear varies greatly from system to system and even document to document. In one test, things seem normal until exactly 166% and then it started being slow. Anything at or above 166% was dreadfully slow and anything below 166% was “normal” speed. If you turn off graphics display ("Graphics On/Off" function- you have to add it manually to the toolbar) then the problem disappears. I have attached a sample document that helps to illustrate the problem. To see the problem clearly, launch LibreOffice through an ssh session to another machine. Then type text in the top frame rapidly and observe the speed. Keep increasing the zoom level then typing and at some point it will suddenly be noticeably slower. The slower the network link and/or slower the Xserver machine, the more noticeable the problem will appear when it starts. The problem doesn't seem to affect Draw (with a graphic on the page background and typing text above it) only Writer. We could replicate this problem in LO 4.3.4, 4.2.6, and 4.0.6, but it doesn't do it in 3.5.7. I have a feeling this is a Linux-only situation (besides, I don't think you can test it with remote rending the same way in MS-Windows or MacOS).
I can not confirm with Version: 4.5.0.0.alpha0+ Build ID: b024e36ddb3b53163d7a01f6f7b5aadb7a858cd9 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-03-31_09:12:20 Version: 4.4.3.0.0+ Build ID: 3eba5eb1774ab621a1f0f4dcc7e82cce6c025b0a TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-4, Time: 2015-03-27_09:07:12 zoom 200% on the same machine, not remote over network
Created attachment 114723 [details] Animated gif of new slow rendering behavior in 4.4.x I can confirm the originally reported behavior up until version 4.3.x, but it looks like rendering performance major took a turn for the worse starting in version 4.4.0. While this report only affects performance while zoomed in, the new post-4.4.0 behavior slows down rendering performance at ANY zoom level. This makes using LO over the network practically unusable with certain documents! This seems to affect any writer documents containing objects with areas set to an imported picture bitmap. I've attached an animated gif showing the difference in performance before and after 4.4.0. To make the example, I... * launched both versions of LO from the same remote machine(dedicated 100base LAN) * loaded the original example file from this report * resized the window to be the same size * set the zoom level to be the same (50%) * quickly scrolling up/down 4 times in each window using the mouse wheel You'll see in the version on the left (4.3.4), rendering is very fast. The version on the right (4.4.2) is incredibly slow and immediately starts lagging behind. In the gif, you'll see that after performing the 4 scrolls under the 4.4.2 window, I move my mouse back to the first window and have to wait for the rendering to catch up. If you perform this same test locally (open two versions side by side), you should be able to tell the difference in performance using the example file, but it might seem less pronounced on a modern machine. Attempting the same test using X11 forwarded over SSH on even a fast internet connection will result in completely unusable performance. The example in the gif was performed without encryption overhead. It looks like the new >440 behavior causes a LOT of extra network traffic. I used jnettop to monitor my local network traffic while performing the same zoomed out test I used to create the gif while remotely running LO. My local system is using 12.1 MB/s (yes, bytes, so ~97 Mb/s) of network traffic displaying the choppy scrolling behavior in the >440 versions. Using the same test with an old version only generated ~ 700 KB/s worth of traffic! It might also be worth noting that when testing this report's originally described behavior using 4.3.4 under various zoom levels, network traffic steadily increases as you zoom in. The point at which performance gets noticeably choppy is when jnettop reads ~11 MB/s: 100% zoom scrolling = 7MB/s Fast 160% zoom scrolling = 9MB/s Fast 165% zoom scrolling = 10MB/s Fast 170% zoom scrolling = 11MB/s SLOW I think it's quite the coincident that scrolling starts getting choppy when the network bandwidth starts getting close to the theoretical limit. I bibisected when this new change in behavior started. Note that this is NOT when this bug report's originally reported behavior started, so I won't tag this bug as bibisected yet. Sorry if this makes things confusing. ac0bb760db68647bcda368fc13810850c888a1fa is the first bad commit commit ac0bb760db68647bcda368fc13810850c888a1fa Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Sat Oct 18 07:12:11 2014 +0000 source-hash-a7e1ffc248bed431693c6d50c02e7c936c67f360 commit a7e1ffc248bed431693c6d50c02e7c936c67f360 Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Tue Jul 1 15:50:28 2014 +0100 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Tue Jul 1 16:43:06 2014 +0100 coverity#706988 Uncaught exception and coverity#706989 Uncaught exception Change-Id: I426ae26f69311effd60c0b60b7f4d677a2e35c80 :100644 100644 dfb919049ad61631d365f9038e78ea6a9bd2057b 554148af8d80ddbf565849328f3bc184847db05e M ccache.log :100644 100644 a9084aa481645c85bc8e09936010199b7ee524de 5aa1008cbe0a3bdd212effcbb0192de2ed947cb6 M commitmsg :100644 100644 f5c919ded771e0566a1a7ec9fbfcd59a2863e972 5a49acee48ed3dce1fda9141f1f51a55251f15c9 M make.log :040000 040000 08cb282a79a428e5cbb828c9a1a84a2808d3dc66 4301dffd0df84a13f6f81e4f0fb67f53900889dd M opt $ git bisect log # bad: [4a3091e95fa263d3e2dd81e56e83996f0bb12287] source-hash-2b5b04e1e62914bf0902dfd7943cdc44499c47a6 # good: [812c4a492375ac47b3557fbb32f5637fc89d60d9] source-hash-dea4a3b9d7182700abeb4dc756a24a9e8dea8474 git bisect start 'latest' 'oldest' # good: [5d0dfb8e62ae61a240f8313c594d4560e7c8e048] source-hash-0c6cd530de13f80795881f61064f1bf1dcc4ea81 git bisect good 5d0dfb8e62ae61a240f8313c594d4560e7c8e048 # bad: [7dfacd0b8bd828331d74c0f79de6e8924bc4e6a5] source-hash-f93ce4f7eb90093d0ea3115d0a1c614612676dbd git bisect bad 7dfacd0b8bd828331d74c0f79de6e8924bc4e6a5 # bad: [1a63057f6378db7c6b8af1171b7b140f7583f246] source-hash-59f84b4a2c082382767f12e0c7a06a3f0b52e721 git bisect bad 1a63057f6378db7c6b8af1171b7b140f7583f246 # good: [3787e4f82e47eaf4fa454afdca671272e50f875b] source-hash-0e09134a4a4cbb0639fc586c560c6fb2765487be git bisect good 3787e4f82e47eaf4fa454afdca671272e50f875b # bad: [13c63ebe51bd9151757981f75b62271c00a47bf1] source-hash-5ccb510ef7dd6688b86038b37563583f64107936 git bisect bad 13c63ebe51bd9151757981f75b62271c00a47bf1 # good: [c6f882c644d407425898f336d5395e4e9c2ba8e3] source-hash-2b9ad2ef6bf904a8c2ec94e58644e8a7f7a36ae3 git bisect good c6f882c644d407425898f336d5395e4e9c2ba8e3 # good: [1efd4fa8897d1c45ae8a92b4cb5d74049cc7dec8] source-hash-0d55277947fbc2f92fb9fe40dcfa804dc619c37a git bisect good 1efd4fa8897d1c45ae8a92b4cb5d74049cc7dec8 # bad: [be4d1e746b8125cb258a718397b8c0deadba09e5] source-hash-be8d4a5d8aa711e8eb9265fd38d17c8290770a0e git bisect bad be4d1e746b8125cb258a718397b8c0deadba09e5 # bad: [ac0bb760db68647bcda368fc13810850c888a1fa] source-hash-a7e1ffc248bed431693c6d50c02e7c936c67f360 git bisect bad ac0bb760db68647bcda368fc13810850c888a1fa # first bad commit: [ac0bb760db68647bcda368fc13810850c888a1fa] source-hash-a7e1ffc248bed431693c6d50c02e7c936c67f360
I am confirming this bug report based on tmacalp's findings (I guess he forgot to mark it that way). I do not know why "raal" can't duplicate, I suggest he try again but also doing it remotely (ssh to another machine, run LibreOffice there, then test). What tmacalp brings up afterwards, however, is an extremely serious regression. I had not tested rendering in 4.5.X with the test document until now. OMG- this is bad. I already send him a message that I think that although the two are related, he should probably produce a new bug report with just the new issue. I say this because I think it might confuse people following these issues if they are not separate. I will also encourage people to address the other bug before revisiting this one, since this one is much less important.
Tmacalpconfirmed, setting to new.
Migrating Whiteboard tags to Keywords: (bibisected, perf)
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
Regression introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=0d55277947fbc2f92fb9fe40dcfa804dc619c37a..a7e1ffc248bed431693c6d50c02e7c936c67f360
No repro with Version: 6.2.0.0.alpha0+ Build ID: 7414e07f52af87094240f5c3d9a0eb764e8642f5 CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-06-24_01:44:59 Locale: nl-NL (nl_NL); Calc: CL
Would be cool to get a re-test with fresh master and X over ssh. crxssi, tmacalp, can you do it?
A general discussion is needed: https://bugs.documentfoundation.org/show_bug.cgi?id=122730
Dear crxssi, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear crxssi, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug