Description: I'm getting some complaints from Impress for Windows users telling that recently it has become very slow in the past months. The attached file is an example: when opened under Impress for Windows editor, CPU load rises a lot (up to 47% on an old Pemtium Dual-COre E6700, 4GB ram). It contains some animated GIFS. No special action are required: just open the file and watch CPU load. Steps to Reproduce: 1. Open the attached file in IMpress 2. Go to task manager and see cpu load 3. Actual Results: High CPU load with some animated GIF Expected Results: Much lower CPU load. Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 147130 [details] An impress slide with animated GIFS which causes high cpu load
Bug confirmed. Without the animated GIF, CPU load is about 0.1%, adding the animated GIF, CPU load will raise to 26%. Change the GIF to another new animated GIF will happen too. both in 版本：6.1.3.2 (x64) 組建 ID：86daf60bf00efa86ad547e59e09d6bb77c699acb CPU 執行緒：4; OS：Windows 10.0; UI 算繪：GL; 語言地區：zh-TW (zh_TW); Calc: CL and Version: 6.3.0.0.alpha0+ (x64) Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55 Locale: zh-TW (zh_TW); UI-Language: en-US Calc: threaded
Also found LibreOffice 3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
(In reply to Telesto from comment #3) > Also found > LibreOffice 3.5.7.2 > Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b True, so not a regression as claimed ("in the past months"). Same load under 5.4, 5.0, 4.3, 3.3... Also on Linux The report in See also *is* a regression, however, and appeared in 5.2. Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 9059457a1a8385cb80b5dd2c797cee77af4222a9 CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk3_kde5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 30 November 2018
CPU load is around 18% Version: 6.4.0.0.alpha0+ (x86) Build ID: c2cb467a1e5194c56bb65706b7965fb2c9241b8f CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-06-29_00:11:35 Locale: nl-NL (nl_NL); UI-Language: en-US Calc: threaded
@Noel I thought you might be interested in this
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/77e260f915e0c77ddb1e915e9fd27ab0bdccc763%5E%21 tdf#121793 speedup VCLXAccessibleStatusBarItem::GetItemText It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
There are a couple of potential issues I have identified: (1) Drawing bitmaps with alpha is very expensive because of our weird split color/alpha stuff. Fixing that is a way off, unfortunately (2) We seem to be doing a complete redraw, instead of a partial one. That might be easier to fix
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/a9de047403ccc2fa4f3b924c5e22a273c4081174%5E%21 tdf#121793 use cairo_path_extents It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/3a0518e439dbf4b31c7f38666a6de78c161193a8%5E%21 tdf#121793 speedup VCLXAccessibleStatusBarItem::GetItemText It will be available in 6.3.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/c80eb85eda40604ff15ccd100c613c11c350ed72%5E%21 tdf#121793 use cairo_path_extents It will be available in 6.3.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #11) > Affected users are encouraged to test the fix and report feedback. I can display animated GIF in Impress only up to 30 sec. and then my X server goes to south – a soft lock-up (mouse works, but rest of my KDE Plasma session is unresponsive). If I ssh to my system, it indicates load over 1, but no processes are shown by top to consume any CPU. ps shows X process being in a state Dsl+. Only way out is to kill LO process and wait for a few minutes – with LO process gone, X recovers at some point and system works as nothing would have happened (except, of course, killing of LO). Version: 6.3.2.2 Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c CPU threads: 2; OS: Linux 5.3; UI render: default; VCL: x11; Locale: lv-LV (lv_LV.utf8); UI-Language: en-US Calc: threaded
Just to be clear – it is NOT KDE Plasma issue – I was able to reproduce it with xinit + twm + xterm + LO Impress + top only. This time I paid more attention to details – while animated GIF was displayed, CPU load was reasonable (patch works), but while I was hovering with a mouse over animated GIF X CPU use rose to 100% and then X stalled (soft lockup). Good old ssh + kill LO + reboot solved the issue (if it can be called a solution). Kernel 5.3.0-gentoo; xorg-server-1.20.5; xf86-video-nouveau-1.0.16.
*** Bug 138121 has been marked as a duplicate of this bug. ***
Not clear why Bug 104878 is See Also and not duplicated. I do it. If someone can explain, feel free to set again New. *** This bug has been marked as a duplicate of bug 104878 ***