Description: Hello, After saving a document with many comments (i believe the problem is here), and changing the list to other and back scrolling becomes slow and right button menu opening as well. I found out that to happen in 5.2.7 5.4.5 6.0.6 and 6.1 RC2 and connected to libreoffice-gtk3 component (details here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890638). In Kubuntu 18.4.1 with Calc 6.0.3 the bug doesn't happen. After File->Reload everything is OK. Best wishes, John P.S. The document cannot be sent. Steps to Reproduce: Save a document and change the list to other and back. Actual Results: Slow scrolling. Expected Results: Not slowing. Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 144526 [details] Slow scrolling while VCL is either GTK2 or GTK3 Hello, This file reproduces the slowness on my system. Please check it. Best wishes, John
I can't reproduce it in Versió: 6.0.6.2 ID de la construcció: 1:6.0.6-0ubuntu0.16.04.1 Fils de CPU: 4; SO: Linux 4.15; Renderitzador de la IU: per defecte; VCL: gtk3; Configuració local: ca-ES (ca_ES.UTF-8); Calc: group nor in Version: 6.2.0.0.alpha0+ Build ID: 3bd8316718fdfed454c01a9c4ae6af6beb34437d CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: threaded Could you please paste the info from Help - about LibreOffice ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the information has been provided
It is important to use newer version of Ubuntu - 18.04. From your info i could suggest that it is 16.04.1. The bug is also absent on Debian 8 with GTK2,3 VCL (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890638), but happens on Debian 9 and Ubuntu 18.04 with GTK2,3 VCL. Probably some library difference makes the bug happen. Best wishes, John
Version: 6.1.0.3 Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1 CPU threads: 16; OS: Linux 4.15; UI render: default; VCL: gtk2; Locale: en-US (C.UTF-8); Calc: group threaded Version: 6.1.0.3 Build ID: libreoffice-6.1.0.3-snap1 CPU threads: 16; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-US (C.UTF-8); Calc: group threaded Best wishes, John
Since the bug reproduces on Fedora 28 and Linux Mint 19 as well, it is probable that all GTK2,3 distributions after 2015-2016 reproduce the bug.
You can't confirm your own bugs. Moving it back to UNCONFIRMED until someone else confirms it.
Ok. Best wishes, John
The saving is awfully slow (and has apparently always been that way, since 3.6.7 at least), but after it completes, I do not notice any slowdown in the scrolling. Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: 8b1501d80dc9d3f42c351c6e026fa737e116cae5 CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; Locale: fi-FI (fi_FI.UTF-8); Calc: threaded Built on 23 September 2018 Arch Linux 64-bit Version 3.6.7.2 (Build ID: e183d5b)
(In reply to Buovjaga from comment #8) It is important to use GTK2, GTK3 VCL and change the sheet after saving to reproduce the bug. Best wishes, John
This bug is also related to the bug 119650 (the same attachment). Best wishes, John
scrolling is smooth and fast Version: 6.2.0.0.alpha0+ Build ID: 5487df9cf7c9d14de9b855f178b5d1194b4ae869 CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: gtk3; Locale: nl-BE (en_US.UTF-8); Calc: threaded
(In reply to john.kirk from comment #9) > (In reply to Buovjaga from comment #8) > > It is important to use GTK2, GTK3 VCL and change the sheet after saving to > reproduce the bug. > > Best wishes, > John I made sure to change sheet back and forth now, but no slowness. Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: 00e10ae3189a4407ffb1a48f836cd52dc9a1b6df CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk2; Locale: fi-FI (fi_FI.UTF-8); Calc: threaded Built on 13 October 2018
Dear Reporter, Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ? You can install it alongside the standard version. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Dear Developer, The bug reproduces in 6.3.0.0.alpha0+. Best wishes, John
(In reply to john.kirk from comment #14) > Dear Developer, > > The bug reproduces in 6.3.0.0.alpha0+. > > Best wishes, > John Hello John, LibreOffice 6.3.1.2 has been just released. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Dear Developer, Scrolling is almost identical to 'before saving' but CPU usage is ~2x and changing sheets still happens with a 2-3 sec lag. Debian 9, Debian 10 while Debian 8 is not affected. Appimage Version: 6.3.4.2 Build ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa Best wishes, John
Not reproducible for me with LibreOffice 6.4.3.0+ built at home under Ubuntu 18.04 x86-64 with Gnome DE. Only changing from a sheet to another is long, no slowness problem with scrolling or right-click menu. Version : 6.4.3.0.0+ Build ID : 2f98d1179479f81b2c4d99004d8fcf7c1bc0c6a5 Threads CPU : 4; OS : Linux 4.15; UI Render : par défaut; VCL: gtk3; Ubuntu_18.04_x86-64 Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded Best regards. JBF
I couldn't reproduce the problem. I think it might just be a problem based on the kind of computer the user is using. Is it a temporary slowing or does it slow down until the application is restarted? If it is a temporary thing then it might just be that your computer is using a lot of your CPU and that slows down and the scrolling gets laggy but if not then it might be a bug. Version: 6.4.6.2 Build ID: 1:6.4.6-0ubuntu0.20.04.1 CPU threads: 6; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
A new major release of LibreOffice is available since this bug was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Dear john.kirk, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Developer, Scrolling is Ok. Still difference in changing sheets speed: 'before saving' - instantly, 'after saving' with a 2-3 sec lag. Debian 10 VM with 1 core. Version: 7.2.0.4 / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 1; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Best wishes, John
(In reply to john.kirk from comment #21) > Scrolling is Ok. Still difference in changing sheets speed: 'before saving' > - instantly, 'after saving' with a 2-3 sec lag. Debian 10 VM with 1 core. This slowness I do repro. It doesn't depend on gtk. I repro it in 6.3, 5.0 and oldest of Linux 43all repo. Also on Windows. After you switch once between all the sheets, the slowness is gone.
Created attachment 174452 [details] Perf flamegraph Took a perf trace of switching a sheet after saving and generated flamegraph. Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 58a5bd793a2ed57077fc598281cc74e16373b877 CPU threads: 8; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded
(In reply to Buovjaga from comment #22) > This slowness I do repro. It doesn't depend on gtk. I repro it in 6.3, 5.0 > and oldest of Linux 43all repo. Also on Windows. > > After you switch once between all the sheets, the slowness is gone. The slowness is not gone when VCL: gtk3. When run "SAL_USE_VCLPLUGIN=gen libreoffice", the slowness is gone after switching sheets. Best wishes, John
(In reply to john.kirk from comment #21) > Scrolling is Ok. Still difference in changing sheets speed: 'before saving' > - instantly, 'after saving' with a 2-3 sec lag. Debian 10 VM with 1 core. Still reproduced with Version: 7.4.0.0.beta1+ / LibreOffice Community Build ID: cdf48e57da6b8a6a5eb4131340fa2c14be135714 CPU threads: 8; OS: Linux 5.18; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded
*** Bug 153301 has been marked as a duplicate of this bug. ***
Is it just me, or has saving become terrible slow Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9c1a48f844eaefc505a5914338b6f444011bf315 CPU threads: 8; OS: macOS 14.3; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded Lots of CPU time spend in SfxItemPool::GetItemSurrogates according to Instruments profile. So I tend the suspect the ITEM refactor...
(In reply to Telesto from comment #27) > Is it just me, or has saving become terrible slow > Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: 9c1a48f844eaefc505a5914338b6f444011bf315 > CPU threads: 8; OS: macOS 14.3; UI render: Skia/Raster; VCL: osx > Locale: nl-NL (nl_NL.UTF-8); UI: en-US > Calc: threaded > > Lots of CPU time spend in SfxItemPool::GetItemSurrogates according to > Instruments profile. So I tend the suspect the ITEM refactor... Can you open a new report for that? Thanks.
(In reply to Buovjaga from comment #28) > (In reply to Telesto from comment #27) > > Is it just me, or has saving become terrible slow > > Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community > > Build ID: 9c1a48f844eaefc505a5914338b6f444011bf315 > > CPU threads: 8; OS: macOS 14.3; UI render: Skia/Raster; VCL: osx > > Locale: nl-NL (nl_NL.UTF-8); UI: en-US > > Calc: threaded > > > > Lots of CPU time spend in SfxItemPool::GetItemSurrogates according to > > Instruments profile. So I tend the suspect the ITEM refactor... > > Can you open a new report for that? Thanks. This was fortunately fixed in bug 161846. About the slow switching of sheets, I still observe it like described in comment 22. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ed9a557e1ceb4ffa4060024b20785f04d227e06c CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded