Writer has poor rendering performance for larger images in documents. It appears especially when moving the viewport down/up (scrolling down/up) and more than a half of an image is displayed (if the images is largely hidden the rendering suddenly speeds up). The more images are displayed the slower the rendering is. The scrolling is "choppy" and the displayed images flicker. Steps to reproduce: 1) Start Writer (a new document is created). 2) Insert a larger image (e.g. using Insert -> Image...); it should be larger than ca. 1000 x 500 pixels for significant results. 3) Move the vieport vertical scrollbar to scroll the document. Expected result: The scrolling proceeds smoothly and the rendered image doesn't flicker. Current result: The scrolling is choppy and the rendered image flickers. Note: Graphics Output settings are left in the default state.
(In reply to Lukas Jelinek from comment #0) > Writer has poor rendering performance for larger images in documents. It > appears especially when moving the viewport down/up (scrolling down/up) and > more than a half of an image is displayed (if the images is largely hidden > the rendering suddenly speeds up). The more images are displayed the slower > the rendering is. The scrolling is "choppy" and the displayed images flicker. > > Steps to reproduce: > 1) Start Writer (a new document is created). > 2) Insert a larger image (e.g. using Insert -> Image...); it should be > larger than ca. 1000 x 500 pixels for significant results. > 3) Move the vieport vertical scrollbar to scroll the document. Hi Lukas, A lot of performance testing can vary based on test documents, test systems, etc. Could you please provide a test document/documents to demonstrate the particular choppy image display? Status -> NEEDINFO (Status back to UNCONFIRMED after you've provided test docs, please)
Created attachment 113234 [details] Test image Hi, the problem occurs for as simple documents as empty ones (where only some images are inserted in) and on all of my computers with various OSes (Windows Vista 32bit, Windows 7 64bit, Kubuntu 14.10 64bit). You can try the image which I attach to this comment (insert it twice or more to give more significant results).
NEEDINFO -> UNCONFIRMED
Could only notice a difference vs. blank document on Windows. The choppiness feels really minor. Didn't notice anything I'd call flickering. Let's still change OS to All as you said you experienced it on Kubuntu. Win 7 Pro 64-bit, LibO Version: 4.4.0.3 Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7 Locale: fi_FI Ubuntu 14.10 64-bit Version: 4.4.0.3 Build ID: 40m0(Build:3) Locale: en_US
i have this problem with documents like this: https://mega.co.nz/#!MEoy0B5K!m3L-xbGip4II1umFb3hPTHzcScYuu6dSQzLpzna6I28 i have this problem id version 3.x and 4.x (din't try version 4.4 yet)
(In reply to Juraj from comment #5) > i have this problem with documents like this: > https://mega.co.nz/#!MEoy0B5K!m3L-xbGip4II1umFb3hPTHzcScYuu6dSQzLpzna6I28 (Next time feel free to upload that directly as an attachment :-) (In reply to Lukas Jelinek from comment #0) > Steps to reproduce: > 1) Start Writer (a new document is created). > 2) Insert a larger image (e.g. using Insert -> Image...); it should be > larger than ca. 1000 x 500 pixels for significant results. > 3) Move the vieport vertical scrollbar to scroll the document. > > Expected result: > The scrolling proceeds smoothly and the rendered image doesn't flicker. > > Current result: > The scrolling is choppy and the rendered image flickers. TESTING with 4.4.0.3 on Ubuntu 14.04, scrolling is rather choppy. Whiteboard -> perf Lukas: did previous version of LibreOffice seem any faster? (I'm curious if this is just a general image-rendering issue, or a regression)
It appears that this performance regression was introduced with the release of LibreOffice 4.2. changed first version affected to 4.2.0.4 added bibisected to whiteboard added regression to keywords increased importance to medium/normal (regressions receive increased priority) I've bibisected: 8aabf2aee6514311020b855a95a6e44bab3a5b0d is the first bad commit commit 8aabf2aee6514311020b855a95a6e44bab3a5b0d Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Wed Nov 27 09:32:23 2013 +0000 source-hash-0aa9ced531b8d85ad067c1d156a9708eea628d78 commit 0aa9ced531b8d85ad067c1d156a9708eea628d78 Author: Tor Lillqvist <tml@collabora.com> AuthorDate: Wed Nov 6 00:43:06 2013 +0200 Commit: Tor Lillqvist <tml@collabora.com> CommitDate: Wed Nov 6 00:44:28 2013 +0200 It's types.rdb now, not udkapi.rdb any more Change-Id: If6e8c4862ec628eb4c052e0fd237f5aef89db8eb :100644 100644 ce5cd8dc3c3a6fdc22ae8e4f63897ab07254eddb 867d2798c91ad285850e29c0e8d0f40548dff4fb M ccache.log :100644 100644 405359894d6958b64eb7f2beb6f8a48550779f95 e461af99260d551289a2dd1f188119438cf1fc19 M commitmsg :100644 100644 0c7b842ac949f66eaa350d1ac25b0d6ccc407841 ab6adaea7a96b5d6d10dda3f10504fd1f005cfcf M make.log :040000 040000 216184b3333359e5a1395b47d1551dd3b61d2f04 d765efa8f9bd443222a2a557954f9dd4997fd3e7 M opt $ git bisect log git bisect start 'last42onmaster' 'last41onmaster' # good: [186181c7d6a957b0fcdbc7ff66866f1abfff988e] source-hash-79850f25987d12c8ee91dfd0f699a562f341bf67 git bisect good 186181c7d6a957b0fcdbc7ff66866f1abfff988e # good: [f0f03d19b3f0418cef7eb8c5b3f060266781016f] source-hash-3ad12d1a540eeb54fbb34afc3b7a76bf9e3207c3 git bisect good f0f03d19b3f0418cef7eb8c5b3f060266781016f # bad: [8aabf2aee6514311020b855a95a6e44bab3a5b0d] source-hash-0aa9ced531b8d85ad067c1d156a9708eea628d78 git bisect bad 8aabf2aee6514311020b855a95a6e44bab3a5b0d # good: [e371c174576801a7865420008f494c0d3f153f1b] source-hash-01a13519e2a12e1e9b61bab1437d340e389e44bf git bisect good e371c174576801a7865420008f494c0d3f153f1b # good: [5c95a5c8caeeb347ef97f337a237d66c35261710] source-hash-a6d89e17995987549db36695f3ea490a18f30ba4 git bisect good 5c95a5c8caeeb347ef97f337a237d66c35261710 # good: [09fe6d4400fefeaa099d0deb9b77c77992ab897b] source-hash-56364430108893afbcf5d2b51c5aaa37e393e7cc git bisect good 09fe6d4400fefeaa099d0deb9b77c77992ab897b # good: [11ac44b0fb233f1f98e2f083598f6720a04e457f] source-hash-3c01203ea657b9a3538f9956591b3d4da5fce6e7 git bisect good 11ac44b0fb233f1f98e2f083598f6720a04e457f # first bad commit: [8aabf2aee6514311020b855a95a6e44bab3a5b0d] source-hash-0aa9ced531b8d85ad067c1d156a9708eea628d78
This is really bad on thin clients (and remote use through ssh), and worse in scope than my somewhat similar bug 88678. The behavior is easy to replicate and affects all documents with graphics added (not just at certain zoom levels). When test scrolling a sample document in 4.1 vs 4.2+, I am seeing more than double the network bandwidth and CPU load. But the curious part is that neither resource is anywhere near pegged, so I am not starved of any resource (on the LO machine or the X11 machine or network) and yet the scrolling still lags far behind real-time (like there are micro sleeps thrown in). It goes from very impressive performance to something very poor, in comparison. And the more images and the bigger they are, the worse the performance becomes. Very much a regression. Based on the instructions of how to set bug "Importance", this seems "tediously slow" and should be marked as high,major which I just changed (please correct if this is wrong).
I have no idea where you got "tedious" or "slow" language. This is a normal bug. Resetting the importance. Normal - can prevent high quality/professional quality work. High - I'll leave the high since it's a regression and bibisected. If it's affecting your clients - I highly suggest (as I have before) getting paid L3 support.
(In reply to Joel Madero from comment #9) > I have no idea where you got "tedious" or "slow" language. Straight out of the "Bug Priority Triage Flowchart Suggestion" chart listed on the document foundation.org: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg Going through it, it says "Does bug cause crash, loss of data, inability to install [...]?" My answer was "no". Next is "Does bug involve a serious glitch such as tediously slow [...]?" My answer was "yes", it then points to "Major, High". > This is a normal bug. Resetting the importance. > > Normal - can prevent high quality/professional quality work. > High - I'll leave the high since it's a regression and bibisected. I have no problem with your changing it, I am not an expert in setting the priority, just trying to follow the given instructions and appreciate your experience and help setting it correctly. Although I might be misinterpreting what it says, I do suggest someone investigate if the flowchart is outdated or has wording problems and might need revision, replacement, or removal. > If it's affecting your clients - I highly suggest (as I have before) getting > paid L3 support. I am not sure if you are confusing "thin clients", with "clients" from my comment. I have no clients. As for paid L3 support, I have no access to funds to do so. So I try to contribute in other ways which I can, including testing, filing bug reports, encouraging co-workers to do the same, promoting LibreOffice and FOSS and open standards, training people to use LO and associated software, answering questions on several FOSS related forums, personal contributions to the EFF and local user groups, etc.
I need to update that flowchart to better explain I think. I don't think a delay when inserting a large image and then having to wait a couple/few seconds is the kind of tedious/slow QA is talking about. We're talking about basically freezes that eat up CPU and/or memory for "quite awhile" (some can freeze your system for several minutes). Else there are lots of normal run of the mill bugs that cause short delays that all would be pushed to "Major" and thus make the status useless. I can think of several in the past couple weeks that I marked as minor that under a "paused for a few seconds" standard would constitute major. I'll add it to my list to update the flowchart to try to clarify. Thanks for pointing out that it's a bit confusing in that area. So - if the pause is more than let's say 30 seconds (completely arbitrary) push it back to major (I haven't tested this bug I was just added to cc), else, minor is appropriate.
(In reply to Joel Madero from comment #11) > So - if the pause is more than let's say 30 seconds (completely arbitrary) > push it back to major (I haven't tested this bug I was just added to cc), > else, minor is appropriate. In this particular case, it is not a matter of a single pause. When the graphic is added, the whole interaction with the document slows down. And the more graphics, the worse it is. Typing, scrolling, dragging, zooming, pretty much all interaction with a graphical document suffers. Working on a newsletter document goes from easy in 4.0/4.1 to downright tedious in 4.2+. I am not sure how one would rate that... it depends on the use case. In cases of using LO over the network with any complex document, it really seems major to me. But I will leave that up to others to decide. I encourage people to test it over a network connection < 10Mb/s to see what I mean (and here I am using a VERY fast host with a reasonably fast Xserver local machine and with a dedicated 100Mb/s LAN connection and even then find it frustrating).
Created attachment 114996 [details] Animated gif of slow rendering behavior in 442 vs 357 I have to agree with crxssi on the severity of this bug. The regression is quite dramatic and is VERY noticeable both locally and remotely. I've attached an animated gif of me running two versions of LibreOffice side-by-side locally, so you can see the difference. The two versions used are 3.5.7.2 on left and 4.4.2.2 on right. They are both running on the same local system. This was tested on a Core 2 Duo e6400 system running Fedora 17. Both versions are using the attachment linked in comment 5. In my gif, I do the following actions in order: 1. Type in 442 (EXTREMELY SLOW!) 2. Scroll down and then up once with mouse wheel in 442 (EXTREMELY SLOW!) 3. Type in 357 (VERY FAST) 4. Scroll down and then up with mouse wheel in 357 (VERY FAST) 5. Scroll down and up a few more times in 357 (VERY FAST) 6. Drag images around in 357 (VERY FAST) 7. Step 2 (scrolling down and then up ONCE in the 442 window) has finally finished and I can finally interact with the window again. I then drag images in the 442 window (EXTREMELY SLOW!) As you can see, the previous behavior was orders of magnitude faster and MUCH more responsive. If anyone is wondering, both libreoffice versions are using the same rendering settings (anti-aliasing/hardware accel on). Though this bug doesn't cause a single pause event that lasts 30 seconds, I'd say it is accurately described by the phrase "tediously slow."
Removing comma from Whiteboard (please use a space to delimit values in this field) https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard#Getting_Started
Migrating Whiteboard tags to Keywords: (bibisected, perf)
Could you please try again in the latest release? I can't reproduce it in Version: 5.3.0.0.alpha0+ Build ID: ae3ec79354f7b4967e736c6a4cd7c08fc52e2b7d CPU Threads: 4; OS Version: Linux 4.2; UI Render: default; Locale: ca-ES (ca_ES.UTF-8); Calc: group
Created attachment 127962 [details] Document for perf testing
(In reply to Buovjaga from comment #17) > Created attachment 127962 [details] > Document for perf testing I can't repro anymore with the original image or this other document. Closing. Win 7 Pro 64-bit Version: 5.3.0.0.alpha0+ Build ID: e2f6c7f0d0cc14f851d7028ff846c5dc658a81c6 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-10-10_23:08:02 Locale: fi-FI (fi_FI); Calc: group