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).

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.

(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.

status NEW according to comment 1

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)

(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?

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

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

Both Chromium and Firefox have not been affected when loading such images.

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 702b58945b51e738cdcc3d383ca38881f9f1338d

    source 702b58945b51e738cdcc3d383ca38881f9f1338d

:040000 040000 f7dad6d704d1dd6ebe3753f07b0eec178cd3b5c5 9768d655e2cf87d8887f3733de34113c248292d2 M      instdir

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

Adding Cc: to Armin Le Grand

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

(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

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.

CC: Tomaz Vajngerl

Hi Tomaz,

Do you have any idea for this? I have noticed you are improving the image handling in LibreOffice, does it help?

*** Bug 117010 has been marked as a duplicate of this bug. ***

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

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.

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

I'm adding this to meta bug 116109, it's GraphicPrimitive2D related

(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.

*** Bug 119832 has been marked as a duplicate of this bug. ***

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

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

Created attachment 152667 [details]
Example file

@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

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

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

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.

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

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

(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.

Taking a look...

Please switch off skia (on Win and others) - or improve it.

(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

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

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...

(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.

(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

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.

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.

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.

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.

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.

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.

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.

@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).

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

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.

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

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.

Version: 7.0.0.3 (x64) windows10-64

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

a workaround for older versions is disabling run of animated pictures in options when performance is slow.

The slowdown on moving mouse over the gif image is alive and kicking & also the dragging image around performance is bad

Version: 7.1.0.0.alpha0+ (x64)
Build ID: 6640d7f405d2970ba2825a9455926cc803284d01
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

FWIW, it's slow on all x11 and GTK3 too

*** Bug 138121 has been marked as a duplicate of this bug. ***

*** Bug 121793 has been marked as a duplicate of this bug. ***

*** Bug 142957 has been marked as a duplicate of this bug. ***

Removing from CC after so many commits after  702b58945b51e738cdcc3d383ca38881f9f1338d (tdf#99519 Added more intelligent handling of animated GIFs)

I think implementing multi-thread and/or multi-process functionality would be helpful for this and any other bugs that have similar behavior.

Version 7.4.1.2 on Linux Mint. I confirm that animated GIF hangs the presentation in Slide Show mode.

I can confirm this bug still exists. I am using LibreOffice 24.2 with Ubuntu 24.04 LTS and putting gifs in the presentation freezes the application.

LibreOffice can implement multi processes to handle a document, the additional processes could be used to handle multimedia.