Issue 82275

Changing to P2 because generally Impress works without these animations. But you
are right, this is serious.
Document is easy to setup: just insert two animations from the gallery into a
impress doc and start the slideshow: the CPU usage goes up to 100% and the
presentation can hardly be stopped or switched to another slide.

Cannot reproduce as described. With WinXP, remote desktop display: slow, but
works. Linux, local display: works.

The speed issue (slower on slideshow than in edit mode) might be due to
different image sizes: when I scale up the edit view, such that the animated
GIFs have similar size, speed is comparable.

And lastly: is this something that got worse in 2.3? FWICT, animated gifs have
always been kind of slow...

See issue 69350 for a previously reported, similar problem.

@metalgimp: is the platform correct? do you really run a 64bit XP?

Created attachment 48967 [details]
Bugdoc

Bugdoc added. This is also slow and hard to stop under linux.

@wg: local display for Linux? And: do you see any change in behaviour from 2.2.1?

Response to various comments and queries:
1) Yes, I have a dual-core 64-bit laptop with XP Pro.  Is XP 64-bit?  No idea.
2) The scaling algorithms are not that difficult, and it is not reasonable to
expect 100% core load -- despite image pixel count -- especially when browsers
do it all the time.
3) Expecting <90 images (100x300x8) to take >2 minutes is not reasonable.
4) Exporting to a browser or Flash has been tempting, but the result is not
professional.
(Not to mention that I spent *many* hours on the supposed supported feature.)

I see no justification for 2.3.1 (no noticeable change from 2.2.1) -> 2.4

*** Issue 82449 has been marked as a duplicate of this issue. ***

Note to self: the bugdoc from issue 82449 looks promising.

I'm out of time for 2.4. Sorry for not being able to provide a fix now.

I will attach another bugdoc with similar problems:

Three slides do contain each one animated gif. In edit view every animated gif
runs fine. In presentation mode the first animated gif is still fine, the second
animated gif runs far too slow, and the third animated gif does not show up at all.

These problems were identically reproduced using...

... OOo 2.3.1 on Ubuntu Linux 7.10
... OOo 2.3.1 on Windows 2000
... OOo 2.3.1 on Windows XP
... OOo-DEV300m3 on Ubuntu Linux 7.10

Here is the bugdoc mentioned above. Due to size limitations I could not attach
to the issue. Please refer to this URL:
http://stefanw.googlegroups.com/web/issue82275.odp

Retargetting due to resource constraints

@cl: what about the regression we're having for 3.0? And, wasn't there a master
fix for this, with these event queue polling methods? Please have a look.

Animated gifs are common in presentations, yet are almost unusable with 
current behavior.
Any chance for this issue to be resolved for 3.1?

I experience samilar problem as described in this bugreport, which makes 
openoffice unusable for presentations. To keep exporting to powerpoint for the 
actual presentation is a bit ridiculous. I think it should be pretty high 
priority to fix this....

My problem:
*) The gif-animations I use work normally in edit mode, but those become 
unworkably slow when displaying in full-screen mode. 
*) CPU usage increases by a factor of 10-100 when going to full-screen 
(although not 100% of a core in my case, but still the increase is very obvious)
*) I've tested on both windows XP (32 bit) and Arch Linux (64 bit version) and 
on different computers, problem exists on both multicore and single core 
machines. 
*) This specific problem exist with both the latest openoffice 3.0 as with the 
older version 2.4. 

I will attach a slide that displays this problem clearly on my PC's. To 
reproduce simply swith between edit and full-screen display mode by F5 and 
observe the speed-difference. Other animations from the same website display 
the same problem of too slow animations when in full-screen mode. 

Created attachment 58501 [details]
Single slide with animated gif. The animation works fine in editting mode, but becomes unworkably slow in full-screen mode.

In OOo 3.1 we had a timing fix for the gif problem during the slideshow. but
looking at the bugdoc shows that we no not spend much cpu time any longer but
the animation is much slower than in the edit view.

@cl->af: please investigate

*** Issue 89234 has been marked as a duplicate of this issue. ***

This is great development, I am looking forward for 3.2 with this fix!
Thanks a lot!
WBR,
KP.

m52 on WinXP would not display gif animation at all in 
full_screen_animations_too_slow.odp in slide show.

Setting target to OOo 3.3.

Similar issue in OO 3.1.1 on FC9. Not being able to include animated .gifs makes
OpenOffice Impress completely unusable for me.

When I include an animated .gif in a presentation, OO just hangs up and becomes
completely unresponsive. Small .gifs don't seem to be a problem.

A sample .gif which works fine in Firefox and PowerPoint but causes OO to hang
can be found here:
http://www.engr.colostate.edu/~jessew/foo.gif

Back to PowerPoint in the meantime :(

Are we on track for 3.3 with this issue?

Philipp,
could you take a look at this issue?
Thanks a lot for your attention.
WBR,
KP.

The description says, this is a slideshow problem (works in edit mode), which
makes af the expert.

The performance problems of animated images have at least three different
components:

1. Rendering of single frames takes too long. 
  This is especially true for the edit view when the image has to be scaled up,
because this is done in software by the graphics manager.  There is an issue for
this, but I can not remember the issue number for that.
It is less a problem of the slide show when a hardware accelerated canvas is in use.

2. Animated GIF has frame durations of 0.  In this case a non-zero default value
is used which is chosen differently in the edit view (about one tenth of a
second) and in the slide show (one second).  Reducing this default duration in
the slide show from one second to one tenth of a second improves the animation
considerably.
The place to fix this is slideshow/source/engine/shapes/gdimtftools.cxx in the
getAnbimationFromGraphic() method.

3. When the slide show is started the animated images are displayed both in the
slide show and still in the edit view.  Disabling animations in the edit view
while the slide show is active improved animation performance considerably (you
can verify this by switching back to the edit view and go to a slide that has no
animated images).  Animations can be disabled by calling the
SdrPaintView::SetAnimationEnabled() method.  At least is should work this way,
which it doesn't.  Issue 112975 covers that problem.

Changed target because a fix for the performance problem depends on several
other issues.

*** Issue 69350 has been marked as a duplicate of this issue. ***

Added dependency.

Issue 113169 takes care of shortening the default frame duration.

Could this also be a RAM problem? For example, 512 Mb not enough memory for OOo to deal with the animated GIFs?

Bug persists in OOo 3.3: animated GIF images are essentially impossible to use in Impress.

Temporary workaround: instead of going through insert -> picture -> from file -> foo.gif, try instead insert-> Movie and Sound -> (display all files) -> foo.gif

The image will appear as a grey square with a question mark in the editor, but plays at full speed and with the loading time you would expect in presentation mode (no noticeable delay for a 2 Mb gif file on a slow-ish machine). The playback speed appears to be increased, however.

This is an important feature, and it seems to have been an issue for 4+ years! Many people need animations in presentations.

Reset assigne to the default "issues@openoffice.apache.org".