Bug 104878 - Impress works very slow with large sized GIF
Summary: Impress works very slow with large sized GIF
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.2.0.4 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, perf, regression
: 117010 119832 (view as bug list)
Depends on:
Blocks: Impress-Images GraphicPrimitive2D-regressions
  Show dependency treegraph
 
Reported: 2016-12-23 10:54 UTC by Volga
Modified: 2019-03-25 10:50 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Bibisect log (2.45 KB, text/plain)
2017-10-03 15:03 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Volga 2016-12-23 10:54:13 UTC
Description:
When I insert a large GIF download from https://en.wikipedia.org/wiki/File:Odessa_TX_Oil_Well_with_Lufkin_320D_pumping_unit.gif and insert into Impress, Impress works very slow, sometimes no response.

Steps to Reproduce:
1. Open Impress
2. Insert GIF download from above resource

Actual Results:  
As description

Expected Results:
Impress should works very well with such GIF


Reproducible: Always

User Profile Reset: No

Additional Info:
Version: 5.3.0.0.beta2+ (x64)
Build ID: 371f0f6770add78ae81e0f769d0490874bca353c
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; 
TinderBox: Win-x86_64@62-TDF, Branch:libreoffice-5-3, Time: 2016-12-22_13:59:31
Locale: zh-CN (zh_CN); Calc: group


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0
Comment 1 Telesto 2016-12-23 13:38:29 UTC
Confirming with:
Version: 5.4.0.0.alpha0+
Build ID: 9cfb2f2f03b5ec086487fd483298466db0b09010
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-12-20_23:58:02
Locale: nl-NL (nl_NL); Calc: CL

Bug is a bit strange. Hovering the mouse above the gif animation lets the CPU usage spike to 25% (four core), even when Impress window isn't active/selected. It runs quite fine in the background however (12% CPU).
Comment 2 Volga 2016-12-24 03:33:01 UTC
Multi-core CPU is very common at this moment. So to resolve this bug, LibO should make full use of multi-core CPU to render image and video.
Comment 3 Volga 2016-12-25 13:13:13 UTC
(In reply to Telesto from comment #1)
> Bug is a bit strange. Hovering the mouse above the gif animation lets the
> CPU usage spike to 25% (four core), even when Impress window isn't
> active/selected. It runs quite fine in the background however (12% CPU).

This problem would affect our user experience, so this should set to major importance.
Comment 4 tommy27 2016-12-27 07:37:25 UTC
status NEW according to comment 1
Comment 5 Telesto 2016-12-27 10:27:59 UTC
Found also in:
Versie: 5.3.0.0.alpha1 
Build ID: f4ca1573fcf445164c068c1046ab5d084e1b005f
CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; 
Locale: nl-NL (nl_NL); Calc: CL

and in:
Versie: 5.2.2.1 
Build ID: 3c2231d4aa4c68281f28ad35a100c092cff84f5d
CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; 
Locale: nl-NL (nl_NL); Calc: CL

but not in:
Version: 5.1.0.3
Build ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; 
Locale: nl-NL (nl_NL)
Comment 6 Volga 2016-12-28 04:21:08 UTC
(In reply to Telesto from comment #1)
> Bug is a bit strange. Hovering the mouse above the gif animation lets the
> CPU usage spike to 25% (four core), even when Impress window isn't
> active/selected. It runs quite fine in the background however (12% CPU).

How about GPU?
Comment 7 Volga 2017-01-23 03:20:23 UTC
I tested again with another GIF get from https://en.wikipedia.org/wiki/File:Quitman_TX_oil_well_with_Lufkin_pumping_unit.gif , then Impress is nearly no responce. To avoid that, LibreOffice should make use of hardware acceleration for animated images.

Version: 5.3.0.2 (x64)
Build ID: 5ad7b2889021c491af62f7930a4b1cb631392f16
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 布局引擎:新; 
Locale: zh-CN (zh_CN); Calc: group
Comment 8 Telesto 2017-05-24 11:30:58 UTC
Still a repro with:
Version: 5.5.0.0.alpha0+
Build ID: d57e6cd9dcc96112994ca2b14ac45896e86b26e5
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-05-18_22:43:07
Locale: nl-NL (nl_NL); Calc: CL
Comment 9 Volga 2017-05-26 12:46:25 UTC
Both Chromium and Firefox have not been affected when loading such images.
Comment 10 Telesto 2017-10-03 15:03:49 UTC
Created attachment 136734 [details]
Bibisect log

~/bibisect-win32-5.2
$ git bisect good
ac653d02d1cc58fb5abdce1ef97772a692d662f7 is the first bad commit
commit ac653d02d1cc58fb5abdce1ef97772a692d662f7
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Fri Jun 10 08:25:09 2016 -0700

    source sha:702b58945b51e738cdcc3d383ca38881f9f1338d

    source sha:702b58945b51e738cdcc3d383ca38881f9f1338d

:040000 040000 f7dad6d704d1dd6ebe3753f07b0eec178cd3b5c5 9768d655e2cf87d8887f3733de34113c248292d2 M      instdir
Comment 11 Telesto 2017-10-03 15:06:29 UTC
author	Armin Le Grand <Armin.Le.Grand@cib.de>	2016-06-03 11:58:40 (GMT)
committer Caolán McNamara <caolanm@redhat.com>	2016-06-10 13:42:57 (GMT)
commit	702b58945b51e738cdcc3d383ca38881f9f1338d (patch)
tree	9c1958b8c44ee5bbc7803765e498d2208b906556
parent	b523e20a8fb8c9c26e7ffdc1b3f5fd06c440985c (diff)

tdf#99519 Added more intelligent handling of animated GIFs
Isolated to a single Primitive2D class based on the AnimatedSwitch-
Primitive2D which does the specializing in one place. Buffers small
GIFs completely, handles 1st frame always buffered, huge GIFs get
animated by just playing he next frame.
To reach more with the current approach we would have to re-implement
AnimatedGIF import, replay it internally on a sys-specific Surface
and blit the current content (with alpha) to our display

https://cgit.freedesktop.org/libreoffice/core/commit/?id=702b58945b51e738cdcc3d383ca38881f9f1338d
Comment 12 Xisco Faulí 2017-10-06 21:34:51 UTC
Adding Cc: to Armin Le Grand
Comment 13 Volga 2017-11-27 10:43:02 UTC
Still repro with:

Version: 6.0.0.0.beta1 (x64)
Build ID:97471ab4eb4db4c487195658631696bb3238656c
CPU 线程:4; 操作系统:Windows 10.0; UI 渲染:默认; 
Locale: zh-CN (zh_CN); Calc: group threaded
Comment 14 Volga 2018-01-31 18:02:33 UTC
(In reply to Volga from comment #13)
> Still repro with:
> 
> Version: 6.0.0.0.beta1 (x64)
> Build ID:97471ab4eb4db4c487195658631696bb3238656c
> CPU 线程:4; 操作系统:Windows 10.0; UI 渲染:默认; 
> Locale: zh-CN (zh_CN); Calc: group threaded

Now this bug still repro with:
Version: 6.0.0.3 (x64)
Build ID:64a0f66915f38c6217de274f0aa8e15618924765
CPU 线程:4; 操作系统:Windows 10.0; UI 渲染:默认; 
区域语言:zh-CN (zh_CN); Calc: group
Comment 15 Telesto 2018-03-15 13:40:57 UTC
CPU usage is fine with:
Version: 6.1.0.0.alpha0+
Build ID: e5bc7fa4e83b33fc3eee343e560a4f8cb91eacd6
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-03-14_23:37:38
Locale: nl-NL (nl_NL); Calc: CL

However, only if there is no mouse pointer above the GIF.
Comment 16 Volga 2018-03-17 07:17:43 UTC
CC: Tomaz Vajngerl
Comment 17 Volga 2018-03-19 16:01:04 UTC
Hi Tomaz,

Do you have any idea for this? I have noticed you are improving the image handling in LibreOffice, does it help?
Comment 18 Telesto 2018-04-14 20:02:04 UTC
*** Bug 117010 has been marked as a duplicate of this bug. ***
Comment 19 Maris Nartiss 2018-04-17 07:12:57 UTC
In Bug 98500 I also observed excessive CPU load while hovering animated GIF with a mouse. Only difference – for X not LO process.

Could it be that both – animation and mouse over events are causing repaints? Judging by the fact how LO UI flickers due to excessive repaints long after finishing resizing window (with a blank document!), this could be the case of executing all repaints instead of queuing them up (and preferably synchronising repaint with vblank).

Version: 6.1.0.0.alpha0+
Build ID: dc823f5fa4a5d2eca56297b9045e5962536c00f9
CPU threads: 2; OS: Linux 4.16; UI render: default; VCL: kde4; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-04-10_23:32:35
Locale: lv-LV (lv_LV.utf8); Calc: group
Comment 20 Volga 2018-06-24 15:51:33 UTC
Still affect me in

Version: 6.1.0.0.beta2 (x64)
Build ID:0f4d2060bc90b4008fbc8e6d9a49ec7eeea60b78
CPU 线程:4; 操作系统:Windows 10.0; UI 渲染:默认; 
区域语言:zh-CN (zh_CN); Calc: group threaded

So need to see how does the next 6.1 test release performanced.
Comment 21 Volga 2018-07-17 08:18:32 UTC
This bug is still present in:

版本:6.1.0.1 (x64)
Build ID:378e26bd4f22a135cef5fa17afd5d4171d8da21a
CPU 线程:4; 操作系统:Windows 10.0; UI 渲染:默认; 
区域语言:zh-CN (zh_CN); Calc: group threaded
Comment 22 Telesto 2018-08-14 18:12:34 UTC
I'm adding this to meta bug 116109, it's GraphicPrimitive2D related
Comment 23 Volga 2018-09-02 12:15:31 UTC
(In reply to Telesto from comment #22)
> I'm adding this to meta bug 116109, it's GraphicPrimitive2D related
So I hope such bugs would be fixed soon, because these bugs are really bad for performance and usability.
Comment 24 Buovjaga 2018-10-05 16:44:35 UTC
*** Bug 119832 has been marked as a duplicate of this bug. ***
Comment 25 Telesto 2019-03-25 10:50:55 UTC
Repro; used Attachment 144828 [details] bug 119832
Version: 6.3.0.0.alpha0+
Build ID: 20ea90a557b5bc744fd234e3a20ab1db484cf88b
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-03-22_03:21:58
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: threaded