Issue 106881 - Impress Unusable for Presenting Multiple Images
Summary: Impress Unusable for Presenting Multiple Images
Alias: None
Product: Impress
Classification: Application
Component: editing (show other issues)
Version: OOO310m19
Hardware: Mac Mac OS X, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2009-11-13 09:33 UTC by petethesweet
Modified: 2017-05-20 11:08 UTC (History)
3 users (show)

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


Note You need to log in before you can comment on or make changes to this issue.
Description petethesweet 2009-11-13 09:33:09 UTC
Impress gets unacceptably slow, produces errors and occasionally hangs when working  with multiple 

Intel iMac, 2.66 GHz Intel Core 2 Duo, 4GB of RAM
OOo 3.1.1 (build 000311m19) on Mac OS X 10.5.8 (latest patches).

Step by step:
1. create plank presentation
2. import jpegs one by one. I used the method of dragging them from a folder in Finder to an empty 
slide. I use jpeg (photos) of about 1 MB each. I put one or 2 pictures on one page. I do not change/edit 
the pictures other than moving on the slide
3. after about 8 or 10 pictures the display does not get updated and the CPU load goes up and uses 
approximately one core at 100% - with no other activity. Pictures are not rendered in Slides pane 
anymore, e.g. When trying to edit *any* object, the spinning beachball often shows up.
4. Adding more pictures (I need about 40 or more for a presentation) leads to errors (cannot move or 
edit in a controlled manner). Impress is not usable anymore.
5. Removing some slides or images from the presentation reverts the system to normal operation.
Comment 1 wolframgarten 2009-11-16 10:28:15 UTC
The non painting thumbnails in the slide pane are reproducible on windows, too.
But the bad system performance seems to be a mac only...
Reassigned. Adding hdu as cc.
Comment 2 2009-11-16 16:18:49 UTC
Profiling the scenario (a presentation with a couple of slides each just containing a big JPEG) shows that 
reading and decoding the JPEGs costs a lot of time.
@sj: Aren't they already in the graphics cache? IIRC there were changes in the way the checksum was 
calculated and/or cached; could this have had a negative impact on the cache hit ratio?
Comment 3 Marcus 2017-05-20 11:08:22 UTC
Reset assigne to the default "".