Description: Fileopen ODT: Long post-processing of a file containing a large table Steps to Reproduce: Steps to Reproduce: 1. Open attachment 149343 [details] (bug 123517) 2. Notice the CPU usage after the file shows up and lines of the table being redrawn Actual Results: Long post processing after file opens. Some lines in the table get redrawn Expected Results: CPU hammering should stop after opening in +/-9 seconds with GDI (and +/-18 seconds with OpenGL) Reproducible: Always User Profile Reset: No Additional Info: Found in Versie: 6.4.0.0.alpha1 (x86) Build ID: cc57df8f942f239d29cb575ea5a7cb01405db787 CPU-threads: 4; Besturingssysteem: Windows 6.3 Build 9600; UI-render: GL; VCL: win; Locale : nl-NL (nl_NL); UI-taal: nl-NL Calc: CL but not in Version: 6.3.0.0.beta1+ (x86) Build ID: 5cfac16dbd4af456a7fb6d52c8953c69a72ba2ba CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
I confirm it with Version: 6.4.0.0.alpha1 (x64) Build ID: cc57df8f942f239d29cb575ea5a7cb01405db787 CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded
Created attachment 155414 [details] tail of terminal output, bibisect-linux-64-6.4 Working in bibisect-linux-64-6.4 repository on debian-buster with VCL=gtk3, I see that the bug entered LibreOffice in commit 058c406c1610df7e557b9405619388465d3f056b Author: Corentin Noël <corentin.noel@collabora.com> Date: Fri Sep 20 18:30:15 2019 +0200 gtk3: Depend on the window stylecontext Make all GtkStyleContext children of the one from the current toplevel and ensures that the scale factor is the same as the parent. Also make sure to load images using the right scaling factor. Change-Id: I491d79941690fc69171e9aac950493dcca7c78f2 Reviewed-on: https://gerrit.libreoffice.org/79311 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> The CPU times I deemed good for probed versions ranged from 8.71 to 10.938 seconds, and for versions I deemed bad from 15.06 to 17.553 seconds. I am removing keyword bibisectRequest and adding keywords bibisected and bisected.
(In reply to Terrence Enger from comment #2) > commit 058c406c1610df7e557b9405619388465d3f056b > Author: Corentin Noël <corentin.noel@collabora.com> > Date: Fri Sep 20 18:30:15 2019 +0200 cc: Corentin Noël
So the bug reports: VCL: win This commit only changed a behavior in GTK3 VCL 🤷♂️️
(In reply to Corentin Noël from comment #4) > So the bug reports: > VCL: win > This commit only changed a behavior in GTK3 VCL 🤷♂️️ My experience reported in comment 2 was all vith VCL:gtk3, which was the default. I did not try other values. BTW, I have no opinion about whether the performance degradation is serious, still less about the seriousness in comparison to the benefits of the patch I pointed to.
Dear Telesto, 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
1 linguistic_DicList_get_implementation 2 SwFieldType::GetXObject 3 SwRect::Clear 4 linguistic_DicList_get_implementation 5 linguistic_DicList_get_implementation 6 SwRect::Clear 7 linguistic_DicList_get_implementation 8 cppu::OWeakAggObject::setDelegator 9 linguistic_DicList_get_implementation 10 linguistic_DicList_get_implementation
Telesto, could you retest in actual version? I test it in last daily and don't see problem.
(In reply to Martin Srdoš from comment #8) > Telesto, could you retest in actual version? I test it in last daily and > don't see problem. Well I still see a single core used for 40 seconds, until CPU drops to 0%. It looks like the cursor is moving through every table cells Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: cdf8e971d5d46df4bcab35a99c4254df9459213f CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-US (nl_NL); UI: en-GB Calc: CL Jumbo
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 30ee52e6c284be1095fdf278439b4c0a7c5982f0 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded