Apache OpenOffice (AOO) Bugzilla – Issue 16280
Chart Generation/Resizing Painfully Slow
Last modified: 2013-02-24 21:21:41 UTC
Generating a chart with about 10,000 elements in Calc takes absolutely forever - in the region of 100 times slower than in MS Excel for the exact same task. Excel takes a fraction of a second, Calc takes over 1 minute. Stretching the chart takes even longer. Copying a chart to the clipboard also takes a similar amount of time. So does pasting, especially into Writer. Open a document with a single embedded chart takes a minute or two. Now imagine what happens if you need a document with, say, 20-30 charts... This has been cross-checked between RedHat 7.0, RedHat 9.0, OpenOffice 1.0.2, and OpenOffice 1.1beta2 (all 4 combinations). Results are the same on all of them.
Created attachment 7297 [details] Sample Writer Document With Embedded Chart
Hi, pls. see: http://graphics.openoffice.org/chart/featurewishes.html We work on it, so i close it.
closed
*** Issue 17919 has been marked as a duplicate of this issue. ***
*** Issue 19627 has been marked as a duplicate of this issue. ***
*** Issue 19615 has been marked as a duplicate of this issue. ***
*** Issue 19741 has been marked as a duplicate of this issue. ***
*** Issue 19993 has been marked as a duplicate of this issue. ***
*** Issue 20326 has been marked as a duplicate of this issue. ***
*** Issue 20656 has been marked as a duplicate of this issue. ***
*** Issue 20749 has been marked as a duplicate of this issue. ***
*** Issue 21445 has been marked as a duplicate of this issue. ***
*** Issue 22593 has been marked as a duplicate of this issue. ***
*** Issue 25081 has been marked as a duplicate of this issue. ***
One workaround I found was to turn off labels on the X axis. I've created a spreadsheet with 6 charts with about 800 elements on the X axis (2+ year time series). Recalculating the spreadsheet took about 5 minutes on a 1 GHz system. Turning off labels on the X axis allows the spreadsheet to recalculate in about 5 seconds. This is with OOo 1.1.0. If it matters, I could determine whether the behavior is linear or quadratic (I believe it's linear). I don't quite understand why this issue has been closed if it hasn't been integrated (it's also not entirely clear to me exactly which item in the feature wishes this is). However, since I've only just registered, it may not be my place to comment on the process...
*** Issue 16449 has been marked as a duplicate of this issue. ***
*** Issue 27185 has been marked as a duplicate of this issue. ***
utomo > kla: I did not find reason for this issue as invalid. also in View issue activity. I think it is not invalid but duplicate to internal issue number. and it still targetted as 2.0. Do I mis anything ? I only found your comments: ------- Additional comments from kla Tue Jul 1 06:14:55 -0700 2003 ------- Hi, pls. see: http://graphics.openoffice.org/chart/featurewishes.html We work on it, so i close it.
I think it is really wrong having this closed. I will take it.
accept
accepted
*** Issue 30962 has been marked as a duplicate of this issue. ***
*** Issue 32318 has been marked as a duplicate of this issue. ***
according to http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=7690 this issue will be set to OOoLater
*** Issue 31671 has been marked as a duplicate of this issue. ***
*** Issue 15689 has been marked as a duplicate of this issue. ***
*** Issue 36627 has been marked as a duplicate of this issue. ***
*** Issue 36795 has been marked as a duplicate of this issue. ***
*** Issue 36773 has been marked as a duplicate of this issue. ***
*** Issue 41300 has been marked as a duplicate of this issue. ***
*** Issue 41566 has been marked as a duplicate of this issue. ***
*** Issue 42336 has been marked as a duplicate of this issue. ***
*** Issue 44287 has been marked as a duplicate of this issue. ***
*** Issue 45878 has been marked as a duplicate of this issue. ***
*** Issue 52925 has been marked as a duplicate of this issue. ***
*** Issue 52550 has been marked as a duplicate of this issue. ***
change target
The same problem exists in OOo 2.0 RC1 with already 1000 rows and 2 columns. Calc is terrible slow if you work on charts and therefore unusable. Please don't release OOo 2.0 with such a bummer! Jake
*** Issue 55413 has been marked as a duplicate of this issue. ***
I am sorry that this Issue will not be fixed in OOo 2.0. The chart team is concentrating on a complete redo of the chart module, which will allow us to fix more bugs and introduce important new features in future. But in the meanwhile only very little will happen at the old chart - I am sorry.
*** Issue 57163 has been marked as a duplicate of this issue. ***
*** Issue 58456 has been marked as a duplicate of this issue. ***
*** Issue 61976 has been marked as a duplicate of this issue. ***
*** Issue 64424 has been marked as a duplicate of this issue. ***
Changed Target to 2.x
*** Issue 66963 has been marked as a duplicate of this issue. ***
I commend the attachements to issue 66963 to the developers. They show a chart with 22 series of 10800 elements causing a crash with spurious out of error condition, and also compare memory usage with the principle competing product. I am really surprised that 66963 has been pointed here, because I reported a defect - my example does, after all, crash Calc. This is a mere enhancement. perhaps it should be upgraded to a defect?
This Issue already 3 years Old. and by the number of duplicate Issue, we need to solve this problems ASAP. So, please consider this Fixed for 2.04 or 2.05 instead of 2.X or 2.? Thanks
->bobharvey: I reopened the issue 66963 to handle the crash. The remaining performance problem will be handled here. Thanks a lot for the great example document and bug description!
->utomo99: The chart is currently reimplemented from scratch to enable further enhancements and fixes as the old code base has become unmaintainable. This reimplementation is the thing that needs to be done ASAP first - sorry.
>> Iha: Thanks. I hope we can get the team working on this issue after that. after almost 1 year of the previous comments, I hope team make a lot of fixs on the Chart. Thanks ------- Additional comments from iha Mon Oct 10 09:19:42 -0700 2005 ------- I am sorry that this Issue will not be fixed in OOo 2.0. The chart team is concentrating on a complete redo of the chart module, which will allow us to fix more bugs and introduce important new features in future. But in the meanwhile only very little will happen at the old chart - I am sorry.
*** Issue 72865 has been marked as a duplicate of this issue. ***
New chart module is imminent - has this been fixed in it? And issue 66963?
I am trying to do a 3d "Deep" plot, 30 rows and 30 columns Every time I change one of the diagram properties it takes quite some time. One thing I did to speed things up was to create the initial chart as 2x2, make changes to the chart/diagram. Then called chart.SetRanges(RangeAddress()) with correct range to create the chart. This make it bearable. It seems that the chart is being re-drawn after each property change. It would be nice to have a method/property called "Refresh" that would tell the object not to redraw while making property changes.
I've also noticed that charts are updated when cell contents change, even if auto-recalculate is turned off. I would expect that with auto-recalculate turned off that nothing -- including charts -- would be updated until I manually recalculate.
@jonheine: Do you use a version which has got the new chart module?
->jonheine: It sounds like you use a macro for creating the chart? In that case you can stop view updates while changing the model with XModel::lockControllers and XModel::unlockControllers. The last call will then renew the view once.
In OOo 2.3 the chart module is completely rewritten. Within the new chart I did several performance improvements. The major two affecting the most examples here are: 1) When for a given resolution a data point would be on the same pixel as its predecessor than no shape is created for the display. This reduces the amount of shapes to be rendered enormously when the data has any continuity. 2) When creating a category chart (bar, line etc. ) for thousands of points there are not any longer created thousands of text labels at the axis, which also reduces the rendering time significantly. Here are some example measurements to demonstrate the improvement: A) Loading attached example IssueReport.sxw on my windows pc takes ~3s in OOo2.3 instead of ~43 s in OOo2.2 B) Loading file.xls attached at duplicate issue 19741 takes 3s in OOo2.3 instead of 100s in OOo2.2 C) Loading file 363.xls from issue 20326 takes 13s instead of 65s D) Loadinf file CDMA.sxc from issue 16449 and switching to sheet 1 takes 6s instead of 100s E) Loading file muzyka.xls from issue 30962 takes 4s instead of 160s F) Loading file test.xls from issue 32318 takes 2s instead of 62s The concrete gain in speed depends on the concrete scenario. But roughly the new chart is an order of magnitude faster than the old one when having many data points. So I set this issue to fixed. When there is further demand for speed up please submit a separate issue. Thanks for your patience during the phase of chart re-implementation.
->Thomas, please verify in the master for OOo 2.3.. Note for current state on the way to OOo 2.4: Unfortunately starting with version src680m234/235 the performance is slightly decreased again caused by a global change in loading of libraries somewhere in framework code. That performance decrease is targeted already with issue 83243. I checked the times measured above in OOo 2.3 and SRC680m233. They are the same. So to verify this issue also on the current master you might want to use a version <= SRC680m233 or wait until issue 83243 is fixed.
Verified on the base of the examples