Apache OpenOffice (AOO) Bugzilla – Issue 82869
performance: 3D charts render very slow
Last modified: 2013-09-25 20:41:43 UTC
Fill 10x10 cells with some data (say, RAND() function) Create chart based on those cells, type 3D-lines, smoothed Viewing performance is bad, every redraw took about 10 seconds on mid-range CPU 20x20 array cause complete freeze for about 1 hour
wrong component, changed to Chart and re-assigned
Created attachment 49086 [details] test doc
sample file for easier testing PS: changing chart type before rendering of current chart type not completed leads to crash
Confirming with m233 on WinXP - chart redraw takes approx 30 seconds on Pentium4 2.4GHz.
The problem is not directly in the smooth part but indirectly. If you set the smooth resolution to 20, this means, that 20 points are calculated between two datapoints. Therefore not 10x10 points have to be drawn but approx. 10x10x20. You see the same performance problem, if you have such an amount of datapoints without smoothing. I'll attach a file with 10x100 datapoints. It has the same performance problem (~10 seconds for redraw) as the smooths lines with 10x10 datapoints and resolution 10. So I think, that the problem is in drawing 3D lines.
Created attachment 49118 [details] 1000 datpoints without smoothing
10x10x20 is only 2000 points to calculate and draw. Modern hardware can easily handle many thousands of triangles per second. It's strange slowness of OOo, especially it claims OpenGL support.
@iha: pls have a look.
Ingrid, please consider this issue for 3.0. Thanks.
*** Issue 90561 has been marked as a duplicate of this issue. ***
@Armin, in case of 3D charts the creation of the shapes itself takes very long whereas the completeRedraw-call is very fast in comparison. Adding a new Shape3DPolygonObject and setting properties at these shapes is what seem to be most expensive here. It somehow feels if every change in the draw model already leads to a complete recalculation and view preparation. Please have a look whether the recalculations can be moved to a later time in process when they are really needed. This might be related to some of the work you are currently on :-). An additional idea. In former times you advised me to create all this single simple polygon shapes for each data point. If I remember correctly the reason was that the area fillings, the shadings and/or the surrounding lines didn't look good with one deep polygon shape. Maybe it is a good time now to reconsider this decision and the reasons as the drawing engine has been reworked? Please let me know your suggestions!
AW: Added to CWS aw075, taking a look. Indeed, the creation over API seems to be the expensive part...
AW: Checked paint and creation, the creation takes ages. Looking deeper shows that most of the time is spent in SvxShape::setSize when a new shae is created using API. That SvxShape::setSize is only for shape initialisation, not really needed for 3D objects. When i do not do that when model is locked and it's a 3d object, i get a huge speed increase. The next blocker is E3dObject::SetRectsDirty and E3dObject::StructureChanged() which also take much time. I tried to not do this when model is locked, but it leads to problems (but the model creation time goes back to 4 seconds). To compensate. i tried to call both methods when the model gets unlocked. This works only partislly, still experimenting... Basic problem indeed is the model data creation in the Model implementation itself. There is simly too much updating and notifying on the way.
AW: All these steps are weak and it's hard to weight their influence to other internal stuff. To see how big the influence of the object count is, i tried to create the stripes with a single PolyPolygon. This DEFINITELY solves the speed problem, but cannot be done topologically (see below). @iha: The reason You need a single 3DPolyPolygonObject per data point is that a 3DPolyPolygonObject defines a single 3D PolyPolygon in one single plane in 3D; it's technically a PolyPolygon to allow topologically the definition of holes (think letter 'O' as polygon, a PolyPolygon is needed). What we would need is a multi-PolyPolygon 3D object (which is topologically something completely different from a PolyPolygon); this leads again to Meta3DObjects (#i97749#?). So, to solve this task it would be possible to make the com.sun.star.drawing.Shape3DPolygonObject a meta-PolyPolygon object; it's only used by chart and not an officiual object. Hmmm...
AW->IHA: There are two possible solutions: (a) Extend the com.sun.star.drawing.Shape3DPolygonObject to a Meta-PolyPolygon object (also adapting HitTest, etc.) (b) Use another, existing 3D object, the extrude object. Please test if (b) is sufficient; this would be the simplest and fastest fix.
Shifting target due to missing resources.
changing target due to resource constraints