Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Impress takes too long to open a presentation|
|Component:||open-import||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Version:||OOo 2.0 Beta||Keywords:||oooqa|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description gnustavo 2005-06-13 19:27:13 UTC
Impress takes about four minutes to open the file impress-stuck.ppt that I'm going to attach to this item. During this time it consumes almost 100% of my CPU. I'm using OOo 1.9.100 on a Debian/Linux (kernel 2.6.8), with a Pentium 4 (1.5 GHz), and 512MB of RAM. Judging from the BTW, I tried to open the file with OOo 1.1.2 and it got stuck forever. (Well, or I haven't have the patience to wait too long.) Gustavo.
Comment 1 gnustavo 2005-06-13 19:28:19 UTC
Created attachment 27144 [details] File that takes too long to open
Comment 2 gnustavo 2005-06-13 19:45:38 UTC
Sorry, I was about to say in the previous post that judging by the progress bar during the file import it's not due to the file size. The progress bar goes quick until about 2/3 of its way and gets stuck there for about two minutes and 30 seconds. Then it bumps a little and gets stuck again for another one minute and 30 seconds. Then it goes quickly to the end. I don't know how this can be usefull, but, just in case. Gustavo.
Comment 3 Regina Henschel 2005-06-13 22:12:47 UTC
I can confirm the descripted behaviour on my system. I've got OOo1.9.104 on WinXP Home with Athon 1,15GHz and 1GB RAM. The file opens quick with PowerPoint 97 and with PowerPointViewer. I saved the file in .odp-format and then opened that file. It then opens quickly so that you get the first page, but the slides, which have a metafile, are empty in the slide pane in the beginning. I scrolled the slide pane and it took a very long time until all the slides are shown in the slide pane. The file has an empty textframe on slide 3. I deleted it in PowerPoint, but that has no effect in opening with OOo.
Comment 4 wolframgarten 2005-06-14 07:43:40 UTC
Comment 5 christian.guenther 2005-06-14 11:31:16 UTC
I can reproduce the bug. Please have a look.
Comment 6 sven.jacobi 2005-06-14 12:19:40 UTC
sj->thb: The most time is spend in the GetDifference method of our vcl PolyPolygon, I think therefor your are already having an issue.
Comment 7 thb 2008-06-27 14:09:21 UTC
@sj: I believe this is nowadays handled by basegfx (at least all ooo-build-based versions don't ship gpc). On the other hand, symbolic clipping is an inherently expensive operation, which we could avoid altogether when rendering emf/wmf directly to the target device. Please take this issue back.