Download it now!
Bug 121793 - Animated gif causes big CPU load
Summary: Animated gif causes big CPU load
Status: RESOLVED DUPLICATE of bug 104878
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.4.0 target:6.3.0.2
Keywords: perf
Depends on:
Blocks: Images-Animated
  Show dependency treegraph
 
Reported: 2018-11-29 09:29 UTC by Giovanni Panozzo
Modified: 2020-11-29 09:20 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
An impress slide with animated GIFS which causes high cpu load (407.46 KB, application/vnd.oasis.opendocument.presentation)
2018-11-29 09:30 UTC, Giovanni Panozzo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Giovanni Panozzo 2018-11-29 09:29:39 UTC
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:
Comment 1 Giovanni Panozzo 2018-11-29 09:30:46 UTC
Created attachment 147130 [details]
An impress slide with animated GIFS which causes high cpu load
Comment 2 Wei Ming Chun 2018-11-29 09:47:58 UTC
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
Comment 3 Telesto 2018-11-29 15:55:08 UTC
Also found
LibreOffice 3.5.7.2 
Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
Comment 4 Buovjaga 2018-11-30 19:22:08 UTC
(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
Comment 5 Telesto 2019-07-06 13:12:22 UTC
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
Comment 6 Telesto 2019-07-06 13:15:22 UTC
@Noel
I thought you might be interested in this
Comment 7 Commit Notification 2019-07-08 10:49:21 UTC
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.
Comment 8 Noel Grandin 2019-07-08 14:48:46 UTC
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
Comment 9 Commit Notification 2019-07-09 09:35:42 UTC
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.
Comment 10 Commit Notification 2019-07-09 12:09:43 UTC
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.
Comment 11 Commit Notification 2019-07-15 11:59:22 UTC
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.
Comment 12 Maris Nartiss 2019-10-28 12:20:04 UTC
(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
Comment 13 Maris Nartiss 2019-10-28 13:30:11 UTC
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.
Comment 14 Timur 2020-11-29 08:57:34 UTC
*** Bug 138121 has been marked as a duplicate of this bug. ***
Comment 15 Timur 2020-11-29 09:20:08 UTC
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 ***