https://bugs.freedesktop.org/show_bug.cgi?id=61270
--- Comment #8 from [email protected] --- My pizza guess regarding Testdokument3.odt was wrong. :-( (But please continue reading.) I tried it (not with pizza, but with potatoes au gratin). Double clicking on Testdokument3.odt (as saved from Linux 4.0.1.1-1) on the Desktop of a freshly booted Windows 7 64 Pro with LibreOffice 3.6.5.2 required "only" some 25 seconds to open. This was with the Navigator displayed - but, surprisingly, it wouldn't get much faster or slower when I disabled/re-enabled that. ?!?!?!? So I tried to save it from the Windows Version, as Testdokument4.odt, and reopen it. Roughly the same result. Then, I changed the zoom factor from "fit horizontally + vertically (both pages at once)" to (actually, I don't know) maybe page width, or 100%. And saved it again. First, this took several minutes for saving. Once again, LibreOffice would not respond, and the respective warning from Windows would appear multiple times, while I finally opened the browser to visit bugzilla. LibreOffice finally terminated, so I tried to open the newly written Testdokument4.odt. This is still ongoing - I've searched this error in bugzilla, not found it, opened thunderbird, come here via Haralds link, logged in, written this report, and in the background, LibreOffice is still displaying a gray Window. (7 Minutes and counting). Needless to say my potatoes are gone and I would have loved to have a pizza by now :-( It looks like that forecast regarding opening time under Windows was not completely wrong - but it might also depend upon the zoom factor?!? And obviously, the bug has multiple facets. It behaves differently between Windows and Linux, in Windows differently between with/without Navigator window, maybe also depending on the zoom factor. Altogether, I guess that really can make it a show stopper for anyone trying to work with forms. When LibreOffice may finally return and I get the final processing time, I will also upload Testdokument4.odt - saved under Windows, with the different zoom factor. Now, it's 16 minutes past pressing the return key... Mind you, the actual contents of Testdokument4 should be the same as in Testdokument3, only the display scaling should differ. I've waited 22 mins by now. I could have put a pizza in the oven and baked it by now... Grr. Why can't computing be moderately deterministic by 2013? If Humanity gets a second change, may I humbly suggest that engineers focus on reliability *only* - instead of adding new registers, memory, objective programming, and thereby merely speeding up processing a million times, and at the same time giving raise to complexity of code by a million times as well, whose outcome may still apear, or it may not - without the user knowing in advance... To be true, I don't expect this to be an endless loop. Task manager says 13% cpu usage - i.e. 100% of one core, just what I've seen before. My previously collected numbers may suggest linearly extrapolated waiting times from 64 secs to 15 mins, but we're at 45 minutes now. So we're clearly on exponential territory by now, aggravated by the Windows environment - exactly what I feared when I first mentioned the pizza. But the possible variation is just so large that I'll cancel the measurement for now. ... Oh, whatdoisayredeterministic or not: here we are. 50 minutes opening time. Just what it needs to eat a pizza (and to make it first). :-) :-) :-) Kind regards, Joerg -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
