Issue 82869

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