https://issues.apache.org/ooo/show_bug.cgi?id=123539
Armin Le Grand <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from Armin Le Grand <[email protected]> --- 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... -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. You are watching all bug changes.
