Issue 82869 - performance: 3D charts render very slow
Summary: performance: 3D charts render very slow
Alias: None
Product: General
Classification: Code
Component: chart (show other issues)
Version: 3.3.0 or older (OOo)
Hardware: All All
: P3 Trivial with 3 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: performance
Depends on:
Blocks: 90135
  Show dependency tree
Reported: 2007-10-23 07:40 UTC by pmike
Modified: 2013-09-25 20:41 UTC (History)
4 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---

test doc (61.36 KB, application/vnd.oasis.opendocument.spreadsheet)
2007-10-23 09:09 UTC, pmike
no flags Details
1000 datpoints without smoothing (84.25 KB, application/vnd.oasis.opendocument.spreadsheet)
2007-10-24 14:03 UTC, Regina Henschel
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description pmike 2007-10-23 07:40:08 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
Comment 1 frank 2007-10-23 08:13:59 UTC
wrong component, changed to Chart and re-assigned
Comment 2 pmike 2007-10-23 09:09:57 UTC
Created attachment 49086 [details]
test doc
Comment 3 pmike 2007-10-23 09:11:32 UTC
sample file for easier testing
PS: changing chart type before rendering of current chart type not completed
leads to crash
Comment 4 kpalagin 2007-10-23 09:36:15 UTC
Confirming with m233 on WinXP - chart redraw takes approx 30 seconds on 
Pentium4 2.4GHz.
Comment 5 Regina Henschel 2007-10-24 14:01:27 UTC
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.
Comment 6 Regina Henschel 2007-10-24 14:03:19 UTC
Created attachment 49118 [details]
1000 datpoints without smoothing
Comment 7 pmike 2007-10-24 14:21:54 UTC
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.
Comment 8 kla 2007-11-06 09:26:56 UTC
@iha: pls have a look.
Comment 9 kpalagin 2008-03-02 06:00:32 UTC
please consider this issue for 3.0.

Comment 10 kla 2008-06-11 09:04:51 UTC
*** Issue 90561 has been marked as a duplicate of this issue. ***
Comment 11 IngridvdM 2009-05-20 17:47:13 UTC
@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!
Comment 12 Armin Le Grand 2009-07-22 15:12:00 UTC
AW: Added to CWS aw075, taking a look. Indeed, the creation over API seems to be
the expensive part...
Comment 13 Armin Le Grand 2009-07-22 17:29:37 UTC
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.
Comment 14 Armin Le Grand 2009-07-23 12:44:23 UTC
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 a meta-PolyPolygon object; it's only
used by chart and not an officiual object. Hmmm...
Comment 15 Armin Le Grand 2009-07-23 13:11:11 UTC
AW->IHA: There are two possible solutions:

(a) Extend the 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.
Comment 16 IngridvdM 2009-09-08 16:56:58 UTC
Shifting target due to missing resources.
Comment 17 IngridvdM 2010-08-17 16:41:35 UTC
changing target due to resource constraints