Apache OpenOffice (AOO) Bugzilla – Issue 50685
Impress takes too long to open a presentation
Last modified: 2013-08-07 15:21:02 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.
Created attachment 27144 [details] File that takes too long to open
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.
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.
Reassigned.
I can reproduce the bug. Please have a look.
sj->thb: The most time is spend in the GetDifference method of our vcl PolyPolygon, I think therefor your are already having an issue.
@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.