Created attachment 171330 [details] Sheets wich multiple graphs Referring to issues 86321 and 87622 this new issue has been created. After resolving issue 86321, when opening 3 private sheets containing 88 graphs and making changes to data and saving the file once, the following happens. Not all graphs are updated when the data is changed. When using F9, the graphs are updated again. The file from issue 87622 has been used as an example. Steps to Reproduce: 1) Open the sample file and save it 3 or more times under a different name. 2) Open the 3 files and change the value in cell B22 to 10 and save the file once. 3) changed the value in cell B2 back to 1 and see if all graphs are adjusted. 4) If not all graphs are adjusted, F9 must be used to adjust the graphs. Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 42e0ea0a6e4f48967d58fa95081c8ba5a6b08bc6 CPU threads: 16; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL
Hereby the correct step in 2): The file from issue 87622 has been used as an example. Steps to Reproduce: 1) Open the sample file and save it 3 or more times under a different name. 2) Open the 3 files and change the value in cell B2 to 10 and save the file once. 3) Changed the value in cell B2 back to 1 and see if all graphs are adjusted. 4) If not all graphs are adjusted, F9 must be used to adjust the graphs.
I can confirm there is a problem, but I am not sure I get the idea of steps to reproduce. Why save as three files? And F9 does not change things for me. Simple (IMHO) steps to reproduce problem: 1) Open the file from comment 1 2) Change the value in B3, e.g. set it to 10 (or delete it) 3) Look at charts Expected behaviour: The second bar in all charts should get height 10 (or disappear if you deleted) Actual behaviour: The first five graphs do not change, only the last 20. However: If you scroll the faulty graph out of view and back, then they are changed. Tested with: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 42e0ea0a6e4f48967d58fa95081c8ba5a6b08bc6 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win Locale: da-DK (da_DK); UI: da-DK Calc: CL Further information: This is still an improvement. If tested with 7.1.2.2 (i.e. before the patch from bug 86321), then scrolling does not change anything.
(In reply to Lars Jødal from comment #2) > I can confirm there is a problem, but I am not sure I get the idea of steps > to reproduce. Why save as three files? This is the case with my private sheet with 88 graphs. Step 2 can be omitted when reviewing the test sheet. > And F9 does not change things for me. When I use F9 after changing the value, the graphs are adjusted, this also happens if you scroll the faulty graph out of view and back, then they are changed. > Simple (IMHO) steps to reproduce problem: > 1) Open the file from comment 1 > 2) Change the value in B3, e.g. set it to 10 (or delete it) > 3) Look at charts > > Expected behaviour: > The second bar in all charts should get height 10 (or disappear if you > deleted) > > Actual behaviour: > The first five graphs do not change, only the last 20. Yes reprocuce > However: If you scroll the faulty graph out of view and back, then they are > changed. Yes reproduce, also when i use F9
I have test "The first five graphs do not change, only the last 20." in: Version: 7.1.2.2 (x64) / LibreOffice Community Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4 CPU threads: 16; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL and didn't reproduce here, "The first five graphs do not change, only the last 20." only in Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 42e0ea0a6e4f48967d58fa95081c8ba5a6b08bc6 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win Locale: da-DK (da_DK); UI: da-DK Calc: CL
(In reply to VLB from comment #4) > I have test "The first five graphs do not change, only the last 20." in: > Version: 7.1.2.2 (x64) / LibreOffice Community > Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4 > CPU threads: 16; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: > win > Locale: nl-NL (nl_NL); UI: nl-NL > Calc: CL Additional information with the test was that the following setting for version 7.1.2.2 was made during the test: Go to Tools-> Options-> LibreOffice → Advanced → Open Expert Configuration → Search for "cache" → Change org.openoffice.Office.Common → Cache → Drawing Engine (OLE_Objects) to e.g. 90 (default value 20). When I set this value back to the default value it is reproduced. A further information test is that in LO 5.4.7.2 the graphs are displayed properly and therefore cannot be reproduced in LO 5.4.7.2.
Testing with old versions, standard setup (no change in cache sizes), I find that the bug appears on 6.0.0.0.beta1, but NOT in 6.0.0.0.alpha1. I.e., the bug seems to be caused by some commit between 6.0.0.0.alpha1 and 6.0.0.0.beta1. Changing earliest affected version to the closest available version number. Version: 6.0.0.0.beta1 (x64) Build ID: 97471ab4eb4db4c487195658631696bb3238656c CPU threads: 4; OS: Windows 10.0; UI render: GL; Locale: da-DK (da_DK); Calc: CL PS: The number of charts updated or not was different in this test than what I found in comment 2, but the important point remains: Not all charts were updated from version 6.0.0.0.beta1 and later versions; and 7.2.0.0.alpha0+ helps (you only need to scroll for update) but does not completely solve the problem.
To prevent the issue from occurring, you can do the following: Go to Tools-> Options-> LibreOffice → Advanced → Open Expert Configuration → Search for "cache" → Change org.openoffice.Office.Common → Cache → Drawing Engine (OLE_Objects) to e.g. 40 (default value 20). When I set this value back to the default value it is reproduced.
(In reply to Lars Jødal from comment #6) > Testing with old versions, standard setup (no change in cache sizes), I find > that the bug appears on 6.0.0.0.beta1, but NOT in 6.0.0.0.alpha1. > > I.e., the bug seems to be caused by some commit between 6.0.0.0.alpha1 and > 6.0.0.0.beta1. Changing earliest affected version to the closest available > version number. > > Version: 6.0.0.0.beta1 (x64) > Build ID: 97471ab4eb4db4c487195658631696bb3238656c > CPU threads: 4; OS: Windows 10.0; UI render: GL; > Locale: da-DK (da_DK); Calc: CL > > PS: The number of charts updated or not was different in this test than what > I found in comment 2, but the important point remains: Not all charts were > updated from version 6.0.0.0.beta1 and later versions; and 7.2.0.0.alpha0+ > helps (you only need to scroll for update) but does not completely solve the > problem. I have also tested it and can confirm that the bug is occurring here.
Results of tests with attachment 171330 [details] and Calcdev 7.1.4.0.0 on Ubuntu 18.04 Very different behaviour than Windows. . . . Opening the attachment, (for example) changing cell B2 from 1 to 10 (Enter). The active cell is now B3 waiting for the User. a. None of the graphics update automatically. However, all the charts can update once simultaneously (on Ubuntu 18.04) by b. Tap Enter key again to move selection to B4. All charts update. c. Use keyboard < ^ v or > to change the cell in view. All charts update. d. Use mouse, click on any other cell. All charts update. e. Use mouse to highlight any column or any row. All charts update. f. Use mouse to click on any Activity or the Ubuntu desktop. All charts update. g. Use F9 works, as for VLB on Windows. h. Scroll the sheet, as for VLB. Charts moved out of view scroll back updated. The charts can all be made to update automatically (on Ubuntu 18.04) i. Before, during or after testing (doesn't matter), double-click a chart. The chart area is highlighted and the Data Ranges cells outline in colours. This is expected "show" behaviour of Calc. Click elsewhere and resume testing by changing any of A2:B9 values. That chart (only) is now automatically updating for all changes. Double-click on each chart(without editing) for every chart. All charts are now automatic updating for all testing. This correct behaviour is not permanent after File>Save or Calc>Close. Saving the file with 7.1.4.0.0dev causes some .xml changes. j. Re-open the new file; it presents the same test results a.to h. k. Workaround Options> > > >Cache from 20 to 40 requires Close application. l. Then restart application (restart Calc). Charts update automatically. Saving the original file once with 5.4.7.2 causes different behaviour at File>open m. At result a., none of the charts updated (Ubuntu 18.04). If the file has been saved at least once using 5.4.7.2, the last twenty charts do update automatically. Multi-threading calculations tested: Results same as above. Software Interpreter on/off test not available here (Open CL is off) Ubuntu 18.04 LTS at latest updated version 24 april 2021 Version: 7.1.4.0.0+ / LibreOffice Community Build ID: 99ca6b660fd911e9e60b63ae286c588aedfb01d0 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:libreoffice-7-1, Time: 2021-04-21_07:55:21 Calc:
Testing on Windows 10 Pro with 7.2.0.0 alpha of 24/04/2021 Same results as for VLB and Lars (Hi!) with additional information . . . . The charts can all be made to update automatically (on Windows) 1. During testing,set any B2:B9 new value. The twenty lower charts update. Double-click one chart that does not update (171330 top row). The chart area is highlighted and the Data Ranges cells outline in colours. This is expected "show the Data Range" behaviour of Calc. Due to this action; (here) All charts in the top row update once. 2. Click elsewhere and resume testing by changing any of A2:B9 values. Only the one chosen chart of the top row is automatically updating. Double-click on each top row chart(without editing). They become active. All charts are now automatic updating for all testing. This corrected behaviour is not permanent after File>Save or Calc>Close. The workaround to have auto-updating (rather than F9 or scroll every time) requires double-clicking all charts at least once after File>Open. Not a very useful workaround (!) yet written here for QA debug information. Useful workaround (here in my project) is to continue with Calc 5.4.7.2 or ask colleagues to modify the Options>Advanced>Expert>Office.Common>Cache>DrawingEngine>Number of OLE_Objects. For QA or developer. I hope this helps too. . . 3. The workaround to scroll the charts off window then back has detail. Open the attachment, change B3 from 2 to 20. Top row charts do not update (as described). Scroll the whole sheet UP sixteen rows: Row 17 is still visible in window. Now scroll down again to show again all the spreadsheet. The "tips" of the histogram for year 2001 have been drawn in blue. Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: b38fd085608a44cf3a2d181e2720c758356647d7 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Created attachment 171427 [details] screencast
(In reply to Xisco Faulí from comment #11) > Created attachment 171427 [details] > screencast LOL, I recorded it with audio. Nevermind, it's pink floyd playing in the background :D
Steps to reproduce: 1. Open attached document 2. Zoom out so all charts are visible 3. Change B2 to 10 -> The first charts are not updated. Scroll down and up fixes the issue. See screencast
not a real regression here. As mentioned in https://bugs.documentfoundation.org/show_bug.cgi?id=86321#c29, This was fixed (maybe by mistake ) in https://cgit.freedesktop.org/libreoffice/core/commit/?id=dc28e90d200a839d4017d548217ee5ce8a23f84 author Noel Grandin <noel@peralex.com> 2014-12-25 15:17:55 +0200 committer Noel Grandin <noel@peralex.com> 2015-01-06 10:59:41 +0200 commit dc28e90d200a839d4017d548217ee5ce8a23f848 (patch) tree a6ae872fb19a046292d96d280da286a20a397def parent 465356ecc81e23016b4289ab16e99084f2a7b84e (diff) fdo#84938: convert IMPORT_ constants to 'enum class' and later reintroduced again in https://cgit.freedesktop.org/libreoffice/core/commit/?id=3e6519714abebf00637c953dbba055d620cfe6f7 author Mike Kaganski <mike.kaganski@collabora.com> 2020-07-20 19:00:13 +0300 committer Mike Kaganski <mike.kaganski@collabora.com> 2020-07-20 21:22:48 +0200 commit 3e6519714abebf00637c953dbba055d620cfe6f7 (patch) tree 58a9292c1ff167edd9e1620d205d5383bfff3e18 parent 4d41b22135904e81f847c1cbf00abc82a414095f (diff) tdf#31231: don't set charts modified state when !IsEnableSetModified Adding Cc: to Mike Kaganski
(In reply to Xisco Faulí from comment #14) The code changed in 3e6519714abebf00637c953dbba055d620cfe6f7 doesn't get called during the updating of the charts in attachment 171427 [details] when source data values (e.g., B2) are modified. Is the bibisect correct?
not a real regression here. As mentioned in https://bugs.documentfoundation.org/show_bug.cgi?id=86321#c29, This was fixed (maybe by mistake ) in https://cgit.freedesktop.org/libreoffice/core/commit/?id=dc28e90d200a839d4017d548217ee5ce8a23f84 author Noel Grandin <noel@peralex.com> 2014-12-25 15:17:55 +0200 committer Noel Grandin <noel@peralex.com> 2015-01-06 10:59:41 +0200 commit dc28e90d200a839d4017d548217ee5ce8a23f848 (patch) tree a6ae872fb19a046292d96d280da286a20a397def parent 465356ecc81e23016b4289ab16e99084f2a7b84e (diff) fdo#84938: convert IMPORT_ constants to 'enum class' and later reintroduced again in https://cgit.freedesktop.org/libreoffice/core/commit/?id=f657454b69c813b90a8b3c1adb2feef1066dbd35 author Mike Kaganski <mike.kaganski@collabora.com> 2017-11-07 13:33:48 +0300 committer Noel Grandin <noel.grandin@collabora.co.uk> 2017-11-07 14:26:11 +0100 commit f657454b69c813b90a8b3c1adb2feef1066dbd35 (patch) tree d1c57e8dc220ae1a5e7d1a2b49025685042318f3 parent 55d00081d0dc4cfa3361fa9da9389042f98773b5 (diff) tdf#31231: properly check for SvXMLImportFlags::ALL Adding Cc: to Mike Kaganski
(In reply to Mike Kaganski from comment #15) > (In reply to Xisco Faulí from comment #14) > The code changed in 3e6519714abebf00637c953dbba055d620cfe6f7 doesn't get > called during the updating of the charts in attachment 171427 [details] when > source data values (e.g., B2) are modified. Is the bibisect correct? Yep, was incorrect. See comment 16
(In reply to Xisco Faulí from comment #16) Heh, f657454b69c813b90a8b3c1adb2feef1066dbd35 still looks strange. Reverting it does not change things for me (it still does not update some of the charts, actually not only the top row, but ~randomly); and anyway, functionally it should not change behavior after initial loading (IIUC). Just in case: this is not to try to deny things, just something is strange here. I honestly do not have an idea what's going on here.
This bug appears to be solved with the shift from 7.3 to 7.4. Using LO 7.3.7.2, I reproduce the problem. Version: 7.3.7.2 (x64) / LibreOffice Community Build ID: e114eadc50a9ff8d8c8a0567d6da8f454beeb84f CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: da-DK (da_DK); UI: da-DK Calc: threaded However, I do NOT reproduce the bug with LO 7.4.3.2. Version: 7.4.3.2 (x64) / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: da-DK (da_DK); UI: da-DK Calc: threaded Mostly for curiosity, testing with a very early 7.4 version, LO 7.4.0.0.alpha1, I also not reproduce the problem, i.e. the difference seems to be 7.3 -> 7.4. (But if it can be confirmed that the bug is solved, it becomes less important exactly what version fixed it - the 7.3.7.2 version was the last in the 7.3.x line anyway.) Version: 7.4.0.0.alpha1 (x64) / LibreOffice Community Build ID: b871abad383583f02eb49c7e49aeae01f6941072 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: da-DK (da_DK); UI: da-DK Calc: threaded
Fixed by commit 1fe08ae6b383c2222178a21c926480a055a87f99 ... which implies that it would likely still fail with more than 200 charts on screen (as opposed to 20 before the change). Possibly that's OK.
Thanks for the notice about which commit (date and tdf#).
I have test in Version: 7.4.3.2 (x64) / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL and it works fine now.
(In reply to Mike Kaganski from comment #20) > Fixed by commit 1fe08ae6b383c2222178a21c926480a055a87f99 > > ... which implies that it would likely still fail with more than 200 charts > on screen (as opposed to 20 before the change). > Possibly that's OK. Fine, we are now three people confirming that it works, and >200 charts is indeed a very high number. Should a new report one day pop up by somebody using that high number, perhaps this thread will be found, and Mike's report on the specific commit can be used. So I'm closing this now as fixed. Thanks for the good work!
*** Bug 137735 has been marked as a duplicate of this bug. ***