Issue 97906 - Starting "Slide Show" caches pixmap data excessively, crashing thin clients
Summary: Starting "Slide Show" caches pixmap data excessively, crashing thin clients
Alias: None
Product: Impress
Classification: Application
Component: viewing (show other issues)
Version: OOo 2.4.1
Hardware: Unknown Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on: 102142
Blocks: 96090
  Show dependency tree
Reported: 2009-01-09 18:09 UTC by lns
Modified: 2017-05-20 11:11 UTC (History)
7 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 lns 2009-01-09 18:09:12 UTC
My environment:
+ Ubuntu 8.04.1 LTS
+ OpenOffice 1:2.4.1-1ubuntu2.1
+ LTSP Environment

Working in OpenOffice Impress/Presentation is fine until starting "Slide Show",
which caches excessive amounts of pixmap data to thin-client memory. This is bad
because thin clients generally have very little amount of RAM (64-128MB is
typical), and when all of the RAM is exhausted by something like excessive
pixmap memory usage, the session simply crashes outright, causing data loss.

Observe my pixmap usage (via 'xrestop') of ~5MB upon simply launching a 1-slide
presentation file:
3e00000 50 84 1 160 62 5495K 5K 5501K 18330 POWER POINT - Impress

Now observe pixmap memory usage of ~52MB upon launching "Slide Show -> Slide Show":
3e00000 56 100 1 230 73 52767K 6K 52773K 18330 POWER POINT - Impress

A Jump of more than 50MB by simply launching the presentation slideshow
shouldn't happen. Thank you for any help on this, the children at my schools
will thank you!


P.S. Please also see triaged Ubuntu bug report located here:
Comment 1 lns 2009-01-09 18:10:33 UTC
Also see previous OOo issue that might have useful information in last comments:
Comment 2 lns 2009-01-09 18:20:31 UTC
Also, hardware acceleration in the Tools->Options->View tabpage is disabled by
default- I enabled it just to see what would happen on my thin client - running
Slide Show from the same presentation gave ~24MB pixmap memory used (from same 5MB
baseline when presentation is simply opened), but things are extremely choppy
when HW Accel is enabled. 
Comment 3 thb 2009-01-10 23:17:42 UTC
Grabbing this one.
Comment 4 thb 2009-01-10 23:22:56 UTC
@Ins: what was the screen res of your thin client again? Slideshow buffers
current display content + current slide background + last/current/next static
slide content, so 5 x worth of full screen display resolution worst case - but
48MB still seems largely obscene...
Comment 5 lns 2009-01-15 19:20:40 UTC
The lab of HP thin clients are all running at 1024x768. Yeah, it seems really
excessive to me as well to buffer all of that stuff.

How hard would it be to have a global OOo option to disable/minimize pixmap
caching in all apps? I was involved in reporting/testing when Writer was having
the same issues with clipart, and it just seems that after this one is fixed,
another one will probably become visible later on. Just a thought.
Comment 6 lns 2009-02-05 23:06:17 UTC
An update on 2/5/2009:

As a follow up for your records, out of 28 sixth graders, 6 thin clients had
to be hard shut down, restarted, killed, logged on again and their Presenter
presentations restored after trying to run their slide show. Didn't seem to
matter with the hardware acceleration. The ones that ran were clunky in the
animations and transitions.
Comment 7 lns 2009-03-05 20:47:15 UTC
Just a *bump* - still getting this issue at a number of my sites. Is there any
light at the end of the tunnel for this one? Lots of unhappy teachers and
students :( Please let me know if I can help provide more info, etc.

- Jordan
Comment 8 thb 2009-03-05 21:22:01 UTC
@lns: sorry, no news from my side at least. Until someone finds time...
Comment 9 lns 2009-03-05 21:35:12 UTC
What can I do to help make time for this issue for you guys? I'm open to ideas,
IANAP but hopefully I can provide something that can help move this along. It's
definitely a priority to me.
Comment 10 lns 2009-04-30 19:01:18 UTC
I just came back from a school a few minutes ago and the computer lab technician
reminded me of this issue - many of the teachers are very frustrated, even the
ones who are supposedly very forgiving. I really, really hope there's something
I can do (can I contract one of you out?) to get this issue resolved for LTSP
thin clients. There are ~1,400 kids using these applications in my district
every day, and most are frustrated that they cannot simply show/preview their
slideshow without the whole system locking up (not to mention the teachers'
frustrations as well).
Comment 11 philipp.lohmann 2009-05-04 09:42:55 UTC
@thb: do you think we can do something in the 3.2 timeframe ? What kind of help
would you need in vcl ?
Comment 12 thb 2009-05-04 12:49:09 UTC
@pl: I reviewed & single-stepped the code a while back; and apparently the most
significant savings can be attained by trimming down buffering in slideshow &
canvas - both likely as runtime options, which is easy for canvas and a bit
involved for slideshow. No promises, but I hopefully can look into slideshow
performance shortly and think about that further there.
Comment 13 thb 2009-05-04 12:55:54 UTC
@pl: now that I think of it - another approach might be to control vcl's pixmap
cache from the outside, e.g. only holding exactly one large pixmap during
slideshow (in a special "memory-saving" mode). But that's a pretty lame
workaround in my book...
Comment 14 caolanm 2009-05-22 14:23:43 UTC
I can see at least one apparently small leak at play (logged separately as issue
Comment 15 lns 2009-07-28 19:58:58 UTC
I am checking in on this bug, as a new school year is starting in 2 weeks - I
really would love to help solve this bug. I read yesterday in a research PDF at that teachers in California schools believe presentation
software such as OOo Presentation is of the top 4 ESSENTIAL programs for
classroom technology use. This issue, for us, is making it impossible for
students to use OOo for this task since we use Linux thin clients.

Please, what can I do to help? The last thing I want is for this bug to cause
our entire thin client infrastructure to be seen as a failure, and for the
district to revert back to Windows.
Comment 16 thb 2009-07-29 08:56:53 UTC
@lns: still on my list for 3.2, I hope to have at least some improvement ready
by then. But no chance for anything within two weeks.
Comment 17 clippka 2009-09-28 14:40:15 UTC
Comment 18 lns 2009-09-28 17:30:39 UTC
Is there any update on this issue besides bumping the milestone to 3.3? I am
starting to get complaints already that nothing has improved for the past 2
years with OOo Presentation/slideshow. I'm getting nervous.
Comment 19 groucho266 2009-09-29 09:44:17 UTC
This task was just assigned to me and I am afraid that I do not know when I will
find the time to look into it.

@lns: There are two things that you can help me with:
1) Please attach a document with which you can reproduce this problem.

2) We have to find out whether this problem is a leak, i.e. a bug in the
implementation, or rather a side effect of the design of slideshow and canvas. 
When you stop and restart a presentation (without closing or reloading the
document), does the memory consumption get worse?
Comment 20 lns 2009-09-30 23:07:12 UTC
@af: Thank you for the reply. You can reproduce this by simply creating a new
slideshow, it shouldn't matter what the contents are. I did an extensive test in
OOo 3.1.0 (OOO310m11 (Build:9399) for Ubuntu (from PPA: ). It seems that this might have
gotten better, but I dunno, I haven't tested this on-site yet, just on my own
thin client with 512mb RAM (many thin clients sold even today by HP only have

LOCAL X SERVER PIXMAP USAGE (gathered from 'xrestop'):
New blank presentation, no background, no effects, medium speed, default
presentation type, "blank slate": 9775k

Place single lizard clipart on slide: 15211k

Move lizard 5 times to different locations: 18091k

Resize lizard 2x, move 2x more: 23572k

Copy slide 3x: 17036k (goes down)

Move slides 2,3,4 to different locations: 17064k

Start slideshow, go through each slide and exit: 32664k (goes down to 17173k
after exiting slideshow)

Start slideshow (second time): 32666k (goes to 17175k after exiting)

Add 3 more random clipart images to slide 1: 16578k 

Start slideshow (third time): 32059k (down to 16576k after exiting)

Close OOo Impress, re-open, create same "blank slate" presentation, create 15
blank slides: 7363k

Start slideshow, cycle through 15 slides: 24634k

Add 2 random clipart images to each slide: 14484k

Start slideshow, cycle through 15 slides: 29112k

So if it's true that the X server will cache previous/current/next slide
content, it almost looks like we're doing better than before somehow. Things are
still very 'clunky' when changing slides, but we're on a terminal server
environment where all the screen content is flowing over the network, including
slideshow graphical content. I will have to test this out again with the other
versions at the schools (which are still on 2.4 version with Ubuntu 8.04) and
their own thin clients (which have only 128mb RAM).

Any insight to what I provided would be greatly appreciated in the meantime.
Comment 21 groucho266 2010-07-07 15:02:26 UTC
The numbers above do not seem to indicate a leak.  I wonder what the numbers are
on Windows.

However, I have to change target due to time constraints.
Comment 22 Marcus 2017-05-20 11:11:21 UTC
Reset assigne to the default "".