Description: Hi, Since I added my sheet "Map" and its graph, my document became extremely long to FILESAVE. It can take up to several minutes, depending on the processor. I only tried i5 CPUs. I could reproduce everything I will describe on Windows 8.1; Windows 10, Mac, Ubuntu 18.04. The spreadsheet seems to handle fields with a lot of difficulty. First of all, it was very long to describe each cell as I had to define one by one every curve to describe my wind field. It is a total of over 1000 curves, each curve being defined by only 2 coordinates. I could not find any easy way to have Calc guess how I described my field on the spreadsheet, because every curve has its own abscissa. Then, I could not find any way to save a default pattern for my new curves to be as thin as possible. Only the color pattern for every new curve can be set as default. One more very slow procedure was to quit the EDITING mode on that particular graph. Several minutes. And then, one can see that it is particular long for Calc to calculate the new graph once an input data is modified. For information, my input cells are yellow. Steps to Reproduce: 1. Open the file "Coefficient BADA par avion avec vent et carte V1.ods" 2. Go to "Map" sheet 3. Try to edit the graph by selecting it and then double-clicking on it. Then, exit the editing mode by selecting any cell. It will take several minutes. 4. Save the file, it will also take several minutes. Actual Results: Calc takes a very long time to exit Editing mode on a graph that contains more than 500 curves, even if the curves are very simple. It also takes a lot of time to display the graph. And also several minutes to save the file, just because of this graph with 1000 small curves. Expected Results: I would like Calc to handle more efficiently and faster fields of data to be displayed. Moreover, it would be very nice to have a specific type of graph to display a field. And finally, it would be very convenient to be able to set the default thickness of the curves. Reproducible: Always User Profile Reset: No Additional Info: Thank you very much for your help, in advance. Hoping I did not miss any obvious solution. Best regards, Guillaume AMELINE PS : My OpenGL details : OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 970/PCIe/SSE2 OpenGL core profile version string: 4.6.0 NVIDIA 390.116 OpenGL core profile shading language version string: 4.60 NVIDIA OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 4.6.0 NVIDIA 390.116 OpenGL shading language version string: 4.60 NVIDIA OpenGL context flags: (none) OpenGL profile mask: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 390.116 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 OpenGL ES profile extensions:
Created attachment 153049 [details] This is my test case Many things are written in French in this document (comments, names...). Please tell me if you would like a translated version, or specific explanations.
Please can you test with a newer version 6.2.5. Verify if you can activate Menu/Tools/Options/LibreOffice/OpenCL OTOH the file has a lot of INDIRECT() functions, it is a volatile function, so every time something change they are recalculated. I think in you case they are easily replaceable with the INDEX() function no volatile and quicker for calculations and for maintenance with no direct text in the function. Comparaisons.G2: INDEX(Tableau.F:F;Filtragevent.$G$2) INDEX(extractionBADA.F:F;C2)
Hi m.a.riosv, I tried with LibreOffice 6.2.5.2 on Windows 10, with openCL activated. The result is the same. something like 5 minutes to save or exit the editing mode on the graph on "Map" sheet. Thank you for your advice about replacing INDIRECT with INDEX. I will take a closer look at this. On the other hand, the culprit is definitely the graph because when you delete it, saving the file only takes few seconds.
Please test the change of the INDIRECT by INDEX, maybe those being part of chart's data are the source of the issue.
Hi again, Replacing INDIRECT with INDEX will take me a tremendous amout of time, even though I am working on it. Meanwhile, I did something quicker. Windows 10 LibreOffice 6.2.5.2 I replaced every formula with plain text, and deleted every sheet except Map. Exiting graph edit mode is now as fast as expected. But saving the file still took 10 minutes with an i3 mobile CPU. The problem definitely seems to be in the way graphs handle a high number of curves, because when you delete the graph and save the file, saving is very fast. OpenCL is activated, here are my OpenGL details on this other computer : Rendereur: Intel(R) HD Graphics 520 Fournisseur: Intel Mémoire: 1024 MO Version: 4.4.0 - Build 21.20.16.4550 Version GLSL: 4.40 - Build 21.20.16.4550 I uploaded a new test file : "test case 2.ods"
Created attachment 153066 [details] sheet and graph only, no formula, plain text.
Comment on attachment 153066 [details] sheet and graph only, no formula, plain text. test case 2.ods
Judt a quick update : I could observe the same heavy behaviour with LibreOffice 6.3.0.4 on Windows 10 Home 1903.
it's a bug, not an enhancement
Thank you Xisco Fauli.
(In reply to guillaume.ameline from comment #7) > Comment on attachment 153066 [details] > sheet and graph only, no formula, plain text. > > test case 2.ods Tested with this and it does take minutes to save (forced exit). Arch Linux 64-bit Version: 7.0.0.0.alpha0+ Build ID: 6a9c7409ee617b79c327dd7ea4de432f448b6006 CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 24 April 2020
Dear guillaume.ameline, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug