Download it now!
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 All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.0.0
Keywords: bibisected, bisected, perf, regression
: 117010 119832 (view as bug list)
Depends on:
Blocks: Impress-Images Images-Animated Regressions-GraphicPrimitive2D
  Show dependency treegraph
 
Reported: 2016-12-23 10:54 UTC by Volga
Modified: 2020-06-21 23:38 UTC (History)
11 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
Flame Graph Win (4.74 MB, image/svg+xml)
2019-05-08 17:23 UTC, Telesto
Details
Example file (875.73 KB, application/vnd.oasis.opendocument.presentation)
2019-07-09 10:14 UTC, Telesto
Details
Example file (5.11 MB, application/vnd.oasis.opendocument.presentation)
2020-03-30 17:44 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
Comment 26 Telesto 2019-05-08 17:23:15 UTC
Created attachment 151250 [details]
Flame Graph Win

Flame Graph Win symbol only build
Version: 6.3.0.0.alpha0+
Build ID: 817e3447053d1a7465a5cf547b4eb39fc46b4d59
CPU threads: 2; OS: Windows 6.3; UI render: default; VCL: win; 
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: threaded
Comment 27 Telesto 2019-07-09 10:14:27 UTC
Created attachment 152667 [details]
Example file
Comment 28 Telesto 2019-07-09 10:20:06 UTC
@Noel
You might be interested in this one too (seeing the fixes for bug 121793). I'm happy already :-). 

Note: it maybe gone already.. I don't have the latest build including your commit(s)

STR
1. Open attachment 152667 [details]
2. However with the mouse pointer above the GIF -> stops animating

Repro with 
Version: 6.4.0.0.alpha0+ (x86)
Build ID: 849b837d1a3b185a8dd893a8f6eaed53605bcab1
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-07-05_03:53:49
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: CL
Comment 29 Telesto 2019-07-10 10:58:01 UTC
Repro with
Version: 6.4.0.0.alpha0+ (x86)
Build ID: 2f2f4767089512c34514896bc37823f9310e9dd4
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-07-10_00:49:53
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: CL
Comment 30 Volga 2019-07-26 18:28:23 UTC
Repro with
版本: 6.3.0.2 (x64)
Build ID: 728469fa359ba8c83d812146293a0b0aa53945ba
CPU 线程: 4; 操作系统: Windows 10.0; UI 渲染: 默认; VCL: win; 
区域语言: zh-CN (zh_CN); UI 语言: zh-CN
Calc: threaded
Comment 31 richard.bu 2019-11-21 10:54:36 UTC
I still have this problem in 

Version: 6.3.3.2
Build ID: 1:6.3.3-0ubuntu0.19.10.1
CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: gtk3; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB
Calc: threaded

I think this bug should get a higher importance rating as it seriously affects the usability.
Comment 32 Postix 2020-02-26 22:14:07 UTC
Can confirm it with LibreOffice 6.4.0.3 on

Operating System: Manjaro Linux 
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.67.0
Qt Version: 5.14.1
Comment 33 paulystefan 2020-03-27 12:20:52 UTC
workaround in LO 6.4 and more

in options of LO
  
in german 

deaktivieren in Barrierefreiheit -> animierte Bilder zulassen 

my translation

deactivate in freedom of walls -> animated pictures running


great work to do with animated gifs in LO

MSO do not animate default in work mode, only in presentation 


so workaround  animated pictures not running default
Comment 34 Postix 2020-03-27 12:24:04 UTC
(In reply to paulystefan from comment #33)
> workaround in LO 6.4 and more

Another possible workaround is converting a GIF into an mp4, which worked fine in my case.
Comment 35 Armin Le Grand 2020-03-30 15:24:25 UTC
Taking a look...
Comment 36 Armin Le Grand 2020-03-30 17:07:28 UTC
Please switch off skia (on Win and others) - or improve it.
Comment 37 Xisco Faulí 2020-03-30 17:09:20 UTC
(In reply to Armin Le Grand from comment #36)
> Please switch off skia (on Win and others) - or improve it.

Don't think it's related to skia, it was first reported back in 2016
Comment 38 Telesto 2020-03-30 17:44:55 UTC
Created attachment 159163 [details]
Example file

Another example
1. Go to sheet 5, select the shape drag it around (over the animating gif)

Not skia related
Comment 39 Armin Le Grand 2020-03-31 08:49:04 UTC
I tried on Win and Linux and both got significantly faster without skia. Indeed the prob is aged, but me and caolan did a lot of opts in that area - so to get the current state - an improvement over 2016 - at lest I had to switch away from skia. Please note that in it‘s current state it does no bufferings (as GDIplus and Cairo do), btw also not using transformations or direct line dashing - but main reasons for bitmap based stuff to be slower again is buffering of system-format bitmaps. Just my 2ct...
There is always room for improving the git stuff, of course, when you know where we came from - it was just painted over timer-based without taking care of Z-Order and overlapping objects at all...
Comment 40 Maris Nartiss 2020-04-03 17:11:06 UTC
(In reply to Armin Le Grand from comment #39)
> I tried on Win and Linux and both got significantly faster without skia.
> Indeed the prob is aged, but me and caolan did a lot of opts in that area -
> so to get the current state - an improvement over 2016 - at lest I had to
> switch away from skia. Please note that in it‘s current state it does no
> bufferings (as GDIplus and Cairo do), btw also not using transformations or
> direct line dashing - but main reasons for bitmap based stuff to be slower
> again is buffering of system-format bitmaps. Just my 2ct...
> There is always room for improving the git stuff, of course, when you know
> where we came from - it was just painted over timer-based without taking
> care of Z-Order and overlapping objects at all...

It is not skia related:
Version: 6.4.2.2
Build ID: 4e471d8c02c9c90f512f7f9ead8875b57fcb1ec3
CPU threads: 2; OS: Linux 5.5; UI render: default; VCL: x11; 
Locale: lv-LV (lv_LV.utf8); UI-Language: en-US
Calc: threaded

Thanks for reminding where we came from. Ahh, those good ol' times when opening a presentation with animated GIF was NOT sending X11 down the drain... Sorry for being emotional. Just spent 10 minutes waiting for VT1 to come up so I could login as root and kill -9 LO Impress process and get my X11 session back without a hard reboot.
Comment 41 Armin Le Grand 2020-04-04 12:36:33 UTC
(In reply to Maris Nartiss from comment #40)
> It is not skia related:
> Version: 6.4.2.2
> Build ID: 4e471d8c02c9c90f512f7f9ead8875b57fcb1ec3
> CPU threads: 2; OS: Linux 5.5; UI render: default; VCL: x11; 
> Locale: lv-LV (lv_LV.utf8); UI-Language: en-US
> Calc: threaded

Of course you are right - it has nothing to do with skia, it‘s a fine system. Let me try to be more precise: It has to do with backends in the office that are not adapted as well as they could be. This includes some (we have seven), but best is Cairo and GDIPlus - load big files and scroll.
This does by no means mean that the others might not catch up and even turn over - hopefully esp. skia will, it has the potential to do so.

Unfortunately x11 is one of those - I currently debug into tdf#113814 and see (i‘m not a x11 specialist) that  11 only has XPixmap and XCopyArea (in principle). Last allows to cc a rect from source, but that‘s the only transformation allowed - no scale, no rotate, no linear algebra ;-( Unfortunately this means that all scaling, masking, rotation (all graphics can be rotated) *has* to be done in SW in preparing XPixmap - this is no good precondition to use any HW in the future for x11.
Maybe you know more/better, please help when you do!

> Thanks for reminding where we came from. Ahh, those good ol' times when
> opening a presentation with animated GIF was NOT sending X11 down the
> drain... Sorry for being emotional. Just spent 10 minutes waiting for VT1 to
> come up so I could login as root and kill -9 LO Impress process and get my
> X11 session back without a hard reboot.

Sigh - I have seen that in x11 backend impl some cache/buffer *is* used for the DDB stuff, but with a gif with many frames these may not live long enough (mem usage opts) and need to be re-created rapidly (up to 30 fps?) - there is always the possibility to enhance the system-independent part of this gif stuff (so all backends would win) - support appreciated :)

regards, alg
Comment 42 Luboš Luňák 2020-04-08 10:08:58 UTC
Moving the cursor slowly over the animation freezes the animation no matter the VCL backend (I've tried kf5, gtk3, win+gdi, win+opengl, win+skia) => this is not a problem of any specific VCL backend. AFAICT the problem is that cursor position change triggers a hit test which for whatever strange reason causes a costly (full?) repaint.

Also, it's rather pointless to complain about Skia in random bugreports or even tell people to "fix" problems by disabling it. First of all, if there's something to complain about, the complaints should go to the responsible person (=me), not bugreports that I'm not even CC-ed on. Second, this bugreport is from 2016, OpenGL became the Windows default in 2015, and Skia drawing is based on OpenGL drawing => if Skia is missing something, it's because you didn't implement it for the most widely used VCL drawing method nor told anyone responsible. This is your responsibility one way or another.
Comment 43 Commit Notification 2020-04-09 10:01:35 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/917fb3c1b09eb145551eae357a1220311261532a

tdf#104878 speed up GfxLink compare

It will be available in 7.0.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 44 Commit Notification 2020-04-09 10:01:47 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/c6a26473f47c141026bf624668607f19394594ca

tdf#104878 avoid OUString allocation in TransformParameters

It will be available in 7.0.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 45 Commit Notification 2020-04-09 10:01:56 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/80a3538d1e68b25fabd03d391ebe3d75e40681bf

tdf#104878 no need to generate invalidations if LOK off

It will be available in 7.0.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 46 Commit Notification 2020-04-09 11:32:09 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/01304a0a3e5d52f46c8519d640ff3787ca3dca7c

tdf#104878 use faster but less accurate cairo_path_extents

It will be available in 7.0.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 47 Commit Notification 2020-04-09 18:21:24 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/4ec7dee3e33cf70abdce9d9de936a9694344d402

tdf#104878 avoid extra deque allocations for empty Primitive2DContainer

It will be available in 7.0.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 48 Commit Notification 2020-04-13 20:48:11 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/981de2fd950af808e8f42a047aeca83687ed2f7b

tdf#104878 related, fix abort()

It will be available in 7.0.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 49 Telesto 2020-04-13 21:54:58 UTC
@Noel
Thanks for all the work you're doing.. however [sorry], i'm not noticing (any?) improvement for main issue..

STR
1. Open attachment 159163 [details]
2. Go to sheet 2 or 5
3. Move the mouse pointer above the GIF -> stops animating (menu hangs).
Comment 50 Telesto 2020-04-13 21:55:41 UTC
Version: 7.0.0.0.alpha0+ (x64)
Build ID: 4475bcd83aac7e033fc5250f268eb922bd471e7b
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; 
Locale: en-US (nl_NL); UI-Language: en-US
Calc: CL
Comment 51 Commit Notification 2020-05-14 09:58:49 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1b5bd34d8430690b19fae0d0febfd810b9525ca2

cache Skia' drawAlphaBitmap() in raster mode (tdf#104878)

It will be available in 7.0.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 52 Telesto 2020-05-21 13:49:59 UTC
Situation has improved with Skia
Version: 7.0.0.0.alpha1+ (x64)
Build ID: 442c7b95e2ee94b66a9854d0cb22f8ecb76532c6
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

Still somewhat slow to drag the GIF around, though
Comment 53 paulystefan 2020-06-21 23:38:20 UTC
Version: 7.0.0.0.beta2 (x64)

looks ok in 7, in 6.4 example was very frozen.

a workaround is disabling run of animated pictures when performance is slow.