Description: Draw file be unresponsive if a large text is pasted into a textbox Steps to Reproduce: 1. Open Draw 2. Go to Format -> Page Properties. Set page size to A0 in Page tab 3. Open attachment 134059 [details] and copy around half of it 4. Create a page filling textbox in draw 5. Paste the text into it (CTRL+SHIFT+V) 6. Draw will be pretty unresponsive Actual Results: Slow and unresponsive Expected Results: Relatively smooth experience as before Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 6.0.0.0.alpha0+ Build ID: cbf371e07fd5dea1ea08a1f299360d1273961ebd CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-06-14_23:13:57 Locale: nl-NL (nl_NL); Calc: CL and in 5.2.4.2 but not in Version: 5.0.0.5 Build ID: 1b1a90865e348b492231e1c451437d7a15bb262b Locale: nl-NL (nl_NL) User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
I can't reproduce it in Version: 6.0.0.0.alpha0+ Build ID: 08f6f9dded1b142b858c455da03319abac691655 CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk2; Locale: ca-ES (ca_ES.UTF-8); Calc: group What do you mean by pretty unresponsive ??
Created attachment 134128 [details] Screencast Hitting 100% CPU usage for quite a while
Created attachment 134243 [details] Callgrind output from master Yes, it was a bit unresponsive. Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha0+ Build ID: 5ff95b16cf9fb2ac7b2b970614e3b98f55978dc0 CPU threads: 8; OS: Linux 4.11; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on June 23rd 2017
> Yes, it was a bit unresponsive. I tend to set it to Windows only. Some or no lag doesn't match the slowness I'm experiencing. It's practically unworkable.
Created attachment 136955 [details] Bibisect log Bisected to: author Noel Grandin <noel@peralex.com> 2015-11-10 12:59:05 (GMT) committer Noel Grandin <noel@peralex.com> 2015-11-10 13:30:03 (GMT) commit 5a7a4325eca58c253270d4e9d327042a9ee2c5f0 (patch) tree fa011fd9303ae9f402931de4b0b6669c641377d4 parent 05b9c892b8568b076a6bc14f45c889e7cd5385ca (diff) editeng: boost::ptr_vector->std::vector<std::unique_ptr> Change-Id: I2b4cdb3809de0e9c69253d2cd05714e15fdc8913
Adding CC to Noel Grandin
*** Bug 113643 has been marked as a duplicate of this bug. ***
Only a small note, bug 113643 (marked as dupe) is a normal user case (a not a corner case, like this one)
Repro comment 0 and bug 113643 comment 2 Version: 6.1.0.0.alpha0+ Build ID: dd4f1b1bd31daf080dc0420524712dc244e539b5 CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-03-20_23:26:38 Locale: nl-NL (nl_NL); Calc: CL
Noel Grandin committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e278df1a14c5cb5dbb7add5d6ed5dd52da131e92 tdf#108608 Draw file unresponsive on large text pasted into textbox It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in Version: 6.1.0.0.alpha0+ Build ID: abf9ec7bef2c341ad9c914fd909dd03b4a784f18 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group
Created attachment 141151 [details] Example file There is still a problem with the duplicate (bug 113643), caused by the same commit (CPU usage increases from 15% to max). 1. Open the attached file 2. Place the cursor somewhere in the yellow text box 3. Click somewhere into the green textbox (notice the text redrawing & slowness & burning CPU
(In reply to Telesto from comment #12) > Created attachment 141151 [details] > Example file > > There is still a problem with the duplicate (bug 113643), caused by the same > commit (CPU usage increases from 15% to max). > 1. Open the attached file > 2. Place the cursor somewhere in the yellow text box > 3. Click somewhere into the green textbox (notice the text redrawing & > slowness & burning CPU Hi Telesto, Thanks for checking the duplicate, I missed it. What do you think, should we create a follow-up bug or reopen the duplicated one?
qre you sure your bisection is accurate? Because my fix had nothing to do with the referenced commit.
BTW, I can't reproduce the problem described in comment 13 in Version: 6.1.0.0.alpha0+ Build ID: abf9ec7bef2c341ad9c914fd909dd03b4a784f18 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: x11; Locale: ca-ES (ca_ES.UTF-8); Calc: group @Telesto, win only? OTOH, could you please bisect it again to be sure it's the same commit ?
(In reply to Xisco Faulí from comment #15) > BTW, I can't reproduce the problem described in comment 13 in > > Version: 6.1.0.0.alpha0+ > Build ID: abf9ec7bef2c341ad9c914fd909dd03b4a784f18 > CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: x11; > Locale: ca-ES (ca_ES.UTF-8); Calc: group > > @Telesto, win only? OTOH, could you please bisect it again to be sure it's > the same commit ? 1. I bibisected this one three times, always the same result. 2. This problem is also noticeable on Linux to some extend (when switch back and forward between yellow and the green textbox quite aggressively; CPU will bump to 80/90%) However, it's way more problematic/ obvious on Windows (switch between both cells is already enough)
Yes, the problem is still bad on Win. I would not call it "smooth" in 5.0 and older, though, but the test case is not entirely normal so it is somewhat to be expected. Version: 6.1.0.0.alpha0+ (x64) Build ID: d39a8e791618a40328c0f90bece3cc246dcf57f7 CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-04-06_00:59:07 Locale: fi-FI (fi_FI); Calc: group
Hm, should have mentioned that I was testing with the original steps from the description.
Created attachment 141170 [details] Example file textbox draw (In reply to Buovjaga from comment #17) > Yes, the problem is still bad on Win. The problem in Draw improved /disappeared in my opinion (tested it without spell check) Version: 6.1.0.0.alpha0+ Build ID: d39a8e791618a40328c0f90bece3cc246dcf57f7 CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-04-05_23:46:48 Locale: nl-NL (nl_NL); Calc: CL However typing text into the textbox is (still?) hammering the CPU. But probably unrelated..
Created attachment 141171 [details] Very Sleepy time profile typing into the draw textbox
Tried with these steps: 1. Copied lorem ipsum up to line 116 2. Disabled spell checking in Draw 3. Drew and text box and pasted 6.1: 20 seconds from pasting to responsiveness (registers click outside box to move focus away) 4.4.7 and 5.0.2: 12 seconds
Hmmm, I think the bibisect repo has a problem in this range, because reverting my original commit makes no change to this bug on Windows.
I think I have a complete fix for this and the related issue, see https://gerrit.libreoffice.org/52623 Note that this is a windows-only fix.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8a94d3dcfa0c37685afd5f966d7fdc1d25dc923d tdf#108608 more Draw text editing responsiveness fixes It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I verify it is now snappy again! Version: 6.1.0.0.alpha0+ Build ID: 84e2614a75a615d6c8584b13a69b3368d2a12a3d CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-04-12_09:11:38 Locale: fi-FI (fi_FI); Calc: group
> I verify it is now snappy again! > > Version: 6.1.0.0.alpha0+ > Build ID: 84e2614a75a615d6c8584b13a69b3368d2a12a3d > CPU threads: 4; OS: Windows 10.0; UI render: default; > TinderBox: Win-x86@42, Branch:master, Time: 2018-04-12_09:11:38 > Locale: fi-FI (fi_FI); Calc: group Indeed, thanks Noel! Version: 6.1.0.0.alpha0+ Build ID: 84e2614a75a615d6c8584b13a69b3368d2a12a3d CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-04-12_09:11:38 Locale: nl-NL (nl_NL); Calc: CL(In reply to Buovjaga from comment #25) -> I will move bug 108608 comment 12 to a different bug report. Still reproducible
for the related bug, 1136364, could someone try out the patch in https://gerrit.libreoffice.org/53371 and see if it helps them, seems to work for me