|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | CRASH when open particular .XLS with 3D Chart | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Calc | Reporter: | liuping <doneyourself> | ||||
| Component: | open-import | Assignee: | Armin Le Grand <Armin.Le.Grand> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | Major | ||||||
| Priority: | P3 | CC: | Armin.Le.Grand, issues, kschenk, rainerbielefeld_ooo_qa | ||||
| Version: | 3.4.0 | Keywords: | crash, needmoreinfo | ||||
| Target Milestone: | 4.1.0 | ||||||
| Hardware: | All | ||||||
| OS: | Windows 7 | ||||||
| Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
| Developer Difficulty: | --- | ||||||
| Attachments: |
|
||||||
Reproducible with reeporter's "AOO 4.0.1 – German UI / German locale [Rev. 1524958 2013-09-20 11:40:29]" on German WIN7 Home Premium (64bit)", “historic” 4.0 User Profile used for all predecessor versions.
Additional Info
(a) Any WIN AOO / LibO OOo (3.0 and later) version I try stops responding with
maximum processor load.
(b) OOo 2.0.3 opens document after long time without
showing chart, same with Calligra Sheets.
(c) Softmaker FreeOffice opens the document without any problems, also
MS EXCEL Viewer
(d) Still Reproducible with "AOO 4.0.1 – German UI / German locale
[Rev. 1524958 2013-09-20 11:40:29]" on German WIN7 Home Premium (64bit)",
“historic” 4.0 User Profile used for all predecessor versions
@liuping
(e) are yuo sure that the chart causes the problem?
(f) Please always contribute information with what OS with what localization
you did your tests!
Checked import, and it is indeed the chart creating 3D objects using the UNO API. Checked that chart in excel viewer and it is made up of a massive count of surfaces. When the chart tries to create all of these, a huge amount of recursion occurs, mainly because the UNO API implementation has to do many resets in the 3D stuff; e.g. when one surface gets inserted/changed, the outmost scene will get invalidates and all 2D BoundRects derived from the 3D BoundRects will be reset. This is due to the fact that AOO has to map the scene content to a single window and thus has to react on each geometry change that may change the default calculated transformation to the 2D canvas of the whole 3D scene. And there are other places where the UNO API correctly has to do such internal resets... Already tried to remove some of these for test purposes, but the shear amount of 3D objects and the usage over the UNO API to be created makes it nearly impossible to improve this, e.g. the UNO API uses the 2D internal GetBoundRect for single 3D objects when their Size is to be set as 2D (no idea why the chart does that, but it happens). That 2D BoundRect depends on the completely calculated 3D scene transform and thus on all other existing objects in that 3D scene which (as explained above) get reset every time a member gets changed in a way that indeed can influence that transformation. Maybe a mode similar to ModelLock should be added to encapsulate 3D scene creations from the chart over the UNO API, but I am not sure how far this can be safely done... Checked again with MS, we talk about a data range of '=data!$A$1:$CW$101', thus potentially 100x100 (10.000) 3D surfaces to create over the UNO API, There are 100 single data ranges defined which use these... Disabled even more stuff for 3D when the model is locked. There are 100 * 100 * 5 * 3 = 150.000 3d shapes involved, and these get created multiple times (xls import to chart model, creation, export of chart model, creation, re-import of chart model, creation). It also has multiple groups of 150.000 objects, so its even more. The 3D chart I get after 130s loading with my quick hacks looks nice and is rendered in 17s using the 3D prmitives using the current 3D software renderer. This shows that the charts object creation using UNO API needs massive rework - it is not designed/implemented currently for such data masses as in this example. My local quick changes will have effects on other 3D areas, it was just a rough test. Doing a more conservative approachand checking for not too dangerous changes to speedup the UNO API object creation. Also will need to buffer the primitive data that ViewContactOfSdrOle2Obj fetches from the chart (using the ChartHelper::tryToGetChartContentAsPrimitive2DSequence tunnel) since this is done each time the range is needed currently, also securing this again with recognizing the chart changes (both not needed wit aw080, btw)... Checked a more simple 3D chart if it still reacts on all events/changes, looks good. Re-checking changes and do some investigations if these may break something else... "alg" committed SVN revision 1569529 into trunk: i123539 some optimizations for 3D chart geometry creation using UNO API Looks good, decided to checkin. Okay, working at all and much faster now. Faster for all types of 3D charts, imported from external format or loading own format. Checked with new build trunk version (still debug version, non-pro, but no concrete debug yet), load to reday chart takes 67s. Will be interesting to see the pro version. Buildbot version needs 37s Build info: AOO410m1(Build:9750) - Rev. 1566593 Linux 32 Won't open file at all and locks up AOO 4.1.0. Request to change to "unresolved". AOO410m1(Build:9750) - Rev. 1570848 Rev.1570848 on windows7 ,Pass Verified on Ubuntu 10.04 (64bit) with build from branch AOO410 (rev. 1583666) Verified on Windows 7 with local build of branch AOO410, rev. 1582710 and with buildbot build, rev. 1582709 OK, now using our RC candidate -- AOO410m15(Build:9761) - Rev. 1583666 2014-04-01 15:58 - Linux i686 KDE 4.10. I WAS able to open this, but when I did anything to it -- clicked on it, etc. there was no response and it hung up my GUI session -- which I exited. At this point, I don't know what the expectations should be regarding processor/memory for a better experience by the end user. Just some questions. Thanks for all the hard work. Hi Kay, thanks for the feedback, much appreciated. On Win7 I have good response times once it is rendered; it *should* be good on linux too, both use the internal software 3D renderer and the same (system-independent) primitive representation. I will take a 2nd look on a linuy system... Tried with the 410 beta on a fresh Fedora64. I get a short 'not responding' message when loading, but not quitting returns to AOO and I can quickly scroll and zoom in the loaded chart. I would guess that the calculation time - even when greatly reduced - is long enough to make the linux ask that question due to AOO not reacting during that time (old singletasking, argh), but all works well and quick. |
Created attachment 81810 [details] sample file Build Info: AOO401m5(Build:9714) - Rev. 1524958 Steps: 1. Open the sample file 2. Check 3D Surface chart in file Defect: Can't load the sheet.