Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||slow or crash with documents in web layout|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Version:||OOo 3.1||Keywords:||crash, performance|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description dfreedman 2009-07-29 20:20:25 UTC
3.1 can't handle documents larger than about 1.0mb under "web layout." Performance is slow to the point of near-freezing, occasionally does freeze for several seconds, and the end or near-end of the document either can't be displayed at all (the screen freezes) or else the end is displayed but the document starts scrolling up on its own and can't be stopped. Every so often (maybe five minutes or so of playing around with it) it crashes 3.1 altogether and sends it into recovery model. These are .odt documents that were created in 2.4 and that worked fine there; resaving them under 3.1 didn't help the situation.
Comment 1 eric.savary 2009-07-30 00:25:01 UTC
Please attach a sample document.
Comment 2 dfreedman 2009-07-30 02:57:38 UTC
Created attachment 63847 [details] 29KB simple text document that 3.1 can't handle in web layout
Comment 3 dfreedman 2009-07-30 03:05:18 UTC
This problem turns out to not be limited to large files. I've attached a file of a mere 29KB that 2.4 handles effortlessly in web layout mode, but that chokes 3.1. The file simply consists of unformatted text (actually the text of this issue page converted to plain text and repeated over and over again, and then saved as an .odt file). I found that 3.1 begins to show what I would call unstable behavior in web layout mode when a file like this is as large as 20KB, and the problem gets worse as the file gets larger, becoming essentially non-functional with files of 29KB--at this length, after the file is loaded it takes 3.1 a minute or so to find the end of the file, and when it does display the file end it starts scrolling up on its own.
Comment 4 Joe Smith 2009-07-30 06:58:04 UTC
The problem seems to be connected to the number of paragraphs, or pages. E.g., a new document with just the dummy autotext (dt,F3) works fine in 2.x and 3.x, but if you search and replace to add a paragraph break after each character, you get a ~30 page document that is slow going into web layout in 2.4.2, but nearly frozen in 3.1. If you watch the status bar as Writer switches to web layout, you can see the page numbers count down to 1. That countdown is slow in 2.4.2 and doesn't seem to block the UI, whereas in 3.1 the page number counts down at maybe 10 seconds per page and the UI is completely blocked while it counts. I tested on Fedora Linux 11, with both Fedora's build and builds from OO.org.
Comment 5 michael.ruess 2009-07-30 09:56:12 UTC
MRU->OD: the attached sample needs extremely long time to be formatted. This was not the case in 2.4. Maybe this is related to issue 100539 though this one here does not contain notes. I was not able to get a crash, maybe dfreedman can send a crash report and post the ID here afterward?
Comment 6 pk72 2009-10-05 13:02:02 UTC
I ran into the same problem. I had a larger file (180kB) saved with web layout and writer would freeze when I tried to open it. Maybe this helps to narrow down when the error got into the code: I was using the OO-package that comes with ubuntu and I am pretty shure the OO version was 3.0.x when I started working with it, no problems then, and the version was still <3.1 when the problem occured.
Comment 7 pk72 2009-10-06 08:08:27 UTC
I heard that bugs are sometimes closed when they occur with the special builds for linux distributions. This is why I want to add that I checked with OO under Windows Vista as well and had the same results: OO Writer 2.4.3 fine OO Writer 3.1.1 freezes when open a larger file that was saved with web layout
Comment 8 forgotmyothername 2010-07-19 00:08:08 UTC
For me in OO 3.2.1, Windows XP SP3: Example document would be 157kb in .txt format, font 10, 206 pages in Print Layout, and with line breaks after every one or two lines which may be related to the issue as "jes" says. Switching it to Web Layout for said document and at the beginning, on the status bar, it'll say that it contain 206 pages. It'll take about 2 to 3 minutes for it to "stabilize" and slowly count down all the way to its true form: 6 pages. If I were to use the scroll bar to go up & down with it for around its first 45 pages or so, the program will be slow and the bar will delay. If I were to scroll all the way down the document then try to go up, the program will hang until it "stabilizes" better / the page count gets lower. But otherwise after it's done stabilizing, I can work with the document like a breeze, scroll just fine, and have no hang-ups. I'd figure a workaround to avoid the wait is to open the document straight to Web Layout mode, but I'm not aware of this option. If so, wouldn't that work to just say 6 pages immediately?