|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | Starting "Slide Show" caches pixmap data excessively, crashing thin clients | ||
|---|---|---|---|
| Product: | Impress | Reporter: | lns <jerickson> |
| Component: | viewing | Assignee: | AOO issues mailing list <issues> |
| Status: | CONFIRMED --- | QA Contact: | |
| Severity: | Trivial | ||
| Priority: | P3 | CC: | caolanm, clippka, groucho266, hdu, issues, philipp.lohmann, www_gmc |
| Version: | OOo 2.4.1 | ||
| Target Milestone: | --- | ||
| Hardware: | Unknown | ||
| OS: | Linux, all | ||
| Issue Type: | DEFECT | Latest Confirmation in: | --- |
| Developer Difficulty: | --- | ||
| Issue Depends on: | 102142 | ||
| Issue Blocks: | 96090 | ||
|
Description
lns
2009-01-09 18:09:12 UTC
Also see previous OOo issue that might have useful information in last comments: http://qa.openoffice.org/issues/show_bug.cgi?id=85321 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. Grabbing this one. @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... 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. 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. 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 @lns: sorry, no news from my side at least. Until someone finds time... 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. 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). @thb: do you think we can do something in the 3.2 timeframe ? What kind of help would you need in vcl ? @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. @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... I can see at least one apparently small leak at play (logged separately as issue 102142) 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 http://nces.ed.gov 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. @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. reassigned 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. 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? @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: http://ppa.launchpad.net/openoffice-pkgs/ubuntu ). 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 128MB): 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. 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. Reset assigne to the default "issues@openoffice.apache.org". |