| Summary: | Calc EDITING, UI: crashes in LO 3.3.4 on Fedora 64 bit | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | entbuggung |
| Component: | Calc | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | LibreOffice, sasha.libreoffice |
| Priority: | medium | Keywords: | perf |
| Version: | 3.3.1 release | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Attachments: |
The demonstration file to reproduce the behaviour described above
backtrace of crash in LibO 3.3.4 |
||
The effect is more or less reproducible with "LibreOffice 3.3.2 – WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:202 / tag 3.3.2.2)]", I don't believe that it's a bug, but may be we can improve LibO a little. Indeed I see a little delay switching to the mentioned sheets, but not a minute but a second with 64 bit AMD Phenom II X4 955 Processor 32.2 GHz, 4GB RAM, Graphic Card: NVIDIA GeForce GT 430. Same behavior with " Ooo 3.3.0 – WIN7 Home Premium (64bit) German UI [OOO330m20 (build 9567)]". Reason for delay are the images in the sheets what are linked contents from WEB. When I break the links so that pictures become embedded, the delay disappears. I checked with WIRESHARK and saw that LibO will update images when the document will be opened and additionally each time when a sheet containing such pictures will be selected. for some applications that might be desired because the the reason for that linking is th show the current picture from web, because creator anticipates that the image might change frequently. But for most application it will be sufficient to load image from WEB 1 time and then using contents from cache. For those applications an option "Take external picture contents from cache for second use" would be useful, especially for CALC, Presentation and also may be DRAW and WRITER. @entbuggung@eismannit.de Can you reproduce my results > @entbuggung@eismannit.de
> Can you reproduce my results
Yes. I deleted the images and everything works fine. The said tabs display quickly. In fact, the images where so far down in the document that I did not even know they were there, or how they got there in the first place (maybe I carelessly copied sth. from the web...).
So, even though that did it, I would still recommend to load these images (no matter whether cached or not) in a child process to keep the document editable while loading. Since the Internet connection is the bottleneck, people like me may be in a disadvantageous situation: I live in China, loading these images from what seems to be an overseas server... slow!
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html > 4. Now switch to one of the tabs "Bücher lesen - Filme schauen" or "Ze Dah".
> Their display is delayed.
not reproducible in LibO 3.6.0 master on Fedora 64 bit
and LibO 3.3.4 repeatedly crashes
Created attachment 56089 [details]
backtrace of crash in LibO 3.3.4
steps to reproduce crash in LibO 3.3.4 on Fedora 64 bit:
1. Load attachment
2. click all tabs from first in order
change title, previous was this: EDITING, UI: Add option "Take external pictures from cache for second use" platform was Windows 32 (In reply to comment #5) > Created attachment 56089 [details] > backtrace of crash in LibO 3.3.4 > > steps to reproduce crash in LibO 3.3.4 on Fedora 64 bit: > 1. Load attachment > 2 [details] [review]. click all tabs from first in order You're a bit alte to report a crash in 3.3.4! If it is working in 3.6 and following correctly then we can close this bug. 3.3, 3.4 and 3.5 are already out of maintenance and even 3.6 is already at 3.6.5 No problem in 3.6.4 on RFR17 64 bit Closing as WFM Migrating Whiteboard tags to Keywords: (perf) [NinjaEdit] |
Created attachment 45795 [details] The demonstration file to reproduce the behaviour described above There is a significant delay of around one minute when switching to certain tabs within a document with several tabs (at least in the attached document). Steps to reproduce this behaviour: 1. Open the attached document Zettel2.ods. 2. There should be a significant delay already while loading the file's content into the editing view. Wait till the document is fully displayed. 3. Switch between the tabs "Bücher", "Legende", "Zeug" and "Verliehen". You will find them to open quickly as expected. 4. Now switch to one of the tabs "Bücher lesen - Filme schauen" or "Ze Dah". Their display is delayed. The file Zettel2.ods was created with the LibreOffice version indicated. The problem described existed in versions of OpenOffice, too, i.e. all the version I had to do with. Thank you for this otherwise great and free software!