Issue 82275 - Created animated GIF too slow & ties up computer
Summary: Created animated GIF too slow & ties up computer
Status: CONFIRMED
Alias: None
Product: Impress
Classification: Application
Component: viewing (show other issues)
Version: OOo 2.3
Hardware: All Windows XP
: P2 Trivial with 6 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
: 69350 82449 89234 (view as issue list)
Depends on: 112975 113169
Blocks:
  Show dependency tree
 
Reported: 2007-10-04 18:22 UTC by metalgimp
Modified: 2017-05-20 11:08 UTC (History)
10 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Bugdoc (53.42 KB, application/vnd.oasis.opendocument.presentation)
2007-10-17 11:59 UTC, wolframgarten
no flags Details
Single slide with animated gif. The animation works fine in editting mode, but becomes unworkably slow in full-screen mode. (1.29 MB, application/vnd.oasis.opendocument.presentation)
2008-12-04 10:28 UTC, moesasji
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description metalgimp 2007-10-04 18:22:21 UTC
(I noticed this defect earlier -- now I can't find the place in the website to
get you the defect number...)
I create or import an animated GIF.  In the edit view, the GIF runs fine and the
CPU usage is nominal.  During presentation mode, the GIF runs 1/10 the speed and
the CPU usage is 100% on one of the CPUs.  I imported a very simple GIF, and I
got the same results.  If it weren't for my Turion 64/X2, I am sure that my
computer would have hung.
I marked this as a P1, because the feature is unusable and severely affects my
computer.
Comment 1 wolframgarten 2007-10-05 09:26:52 UTC
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.
Comment 2 thb 2007-10-17 09:30:48 UTC
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...
Comment 3 thb 2007-10-17 09:35:32 UTC
See issue 69350 for a previously reported, similar problem.

@metalgimp: is the platform correct? do you really run a 64bit XP?
Comment 4 wolframgarten 2007-10-17 11:59:05 UTC
Created attachment 48967 [details]
Bugdoc
Comment 5 wolframgarten 2007-10-17 12:00:20 UTC
Bugdoc added. This is also slow and hard to stop under linux.
Comment 6 thb 2007-10-17 15:07:46 UTC
@wg: local display for Linux? And: do you see any change in behaviour from 2.2.1?
Comment 7 metalgimp 2007-10-17 16:01:12 UTC
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.)
Comment 8 thb 2007-10-21 00:06:07 UTC
I see no justification for 2.3.1 (no noticeable change from 2.2.1) -> 2.4
Comment 9 thb 2007-12-19 16:10:56 UTC
*** Issue 82449 has been marked as a duplicate of this issue. ***
Comment 10 thb 2007-12-19 16:11:42 UTC
Note to self: the bugdoc from issue 82449 looks promising.
Comment 11 thb 2008-01-15 09:08:43 UTC
I'm out of time for 2.4. Sorry for not being able to provide a fix now.
Comment 12 niederbayern 2008-03-22 20:58:02 UTC
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
Comment 13 niederbayern 2008-03-22 21:09:33 UTC
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
Comment 14 thb 2008-06-04 16:59:56 UTC
Retargetting due to resource constraints
Comment 15 thb 2008-06-04 17:43:21 UTC
@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.
Comment 16 kpalagin 2008-11-14 19:49:51 UTC
Animated gifs are common in presentations, yet are almost unusable with 
current behavior.
Any chance for this issue to be resolved for 3.1?
Comment 17 moesasji 2008-12-04 10:26:34 UTC
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. 

Comment 18 moesasji 2008-12-04 10:28:35 UTC
Created attachment 58501 [details]
Single slide with animated gif. The animation works fine in editting mode, but becomes unworkably slow in full-screen mode.
Comment 19 clippka 2009-04-20 17:10:23 UTC
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
Comment 20 clippka 2009-04-20 17:25:27 UTC
*** Issue 89234 has been marked as a duplicate of this issue. ***
Comment 21 kpalagin 2009-04-21 04:37:21 UTC
This is great development, I am looking forward for 3.2 with this fix!
Thanks a lot!
WBR,
KP.
Comment 22 kpalagin 2009-07-20 15:02:38 UTC
m52 on WinXP would not display gif animation at all in 
full_screen_animations_too_slow.odp in slide show.
Comment 23 groucho266 2009-09-25 10:08:16 UTC
Setting target to OOo 3.3.
Comment 24 syrex314 2009-10-13 22:11:16 UTC
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 :(
Comment 25 kpalagin 2010-03-03 20:09:32 UTC
Are we on track for 3.3 with this issue?
Comment 26 kpalagin 2010-03-24 16:24:34 UTC
Philipp,
could you take a look at this issue?
Thanks a lot for your attention.
WBR,
KP.
Comment 27 philipp.lohmann 2010-03-24 16:54:59 UTC
The description says, this is a slideshow problem (works in edit mode), which
makes af the expert.
Comment 28 groucho266 2010-07-06 15:42:14 UTC
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.
Comment 29 groucho266 2010-07-06 15:43:21 UTC
Changed target because a fix for the performance problem depends on several
other issues.
Comment 30 groucho266 2010-07-07 10:59:23 UTC
*** Issue 69350 has been marked as a duplicate of this issue. ***
Comment 31 groucho266 2010-07-15 15:50:12 UTC
Added dependency.
Comment 32 groucho266 2010-07-15 15:51:18 UTC
Issue 113169 takes care of shortening the default frame duration.
Comment 33 websterhamster 2011-05-24 20:55:40 UTC
Could this also be a RAM problem? For example, 512 Mb not enough memory for OOo to deal with the animated GIFs?
Comment 34 thomasdchapman 2011-10-25 16:35:59 UTC
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.
Comment 35 Marcus 2017-05-20 11:08:32 UTC
Reset assigne to the default "issues@openoffice.apache.org".