Issue 106881

Summary: Impress Unusable for Presenting Multiple Images
Product: Impress Reporter: petethesweet <peter.sladeczek>
Component: editingAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: hdu, issues, sven.jacobi
Version: OOO310m19   
Target Milestone: ---   
Hardware: Mac   
OS: Mac OS X, all   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---

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