Issue 98907

Summary: performance: rendering charts takes much longer than before
Product: Draw Reporter: IngridvdM
Component: uiAssignee: AOO issues mailing list <issues>
Status: ACCEPTED --- QA Contact:
Severity: Trivial    
Priority: P4 CC: ahz001, issues, ooo, stephan_schaefer
Version: DEV300m30Keywords: performance, regression
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Description Flags
example chart
example with a big line chart none

Description IngridvdM 2009-02-05 09:51:19 UTC
Load the attached document with a chart created from 5000 data points.
Double click the chart to activate the edit mode and move the legend or the
diagram via mouse. Now observe how long it takes from releasing the mouse until
the chart is re-rendered completely:
In OOo 3.0 on my computer it took ~1,5 seconds.
dev300m29: ~1,5 sec
dev300m30: ~5sec
dev300m39: ~5sec without anti aliasing ~5,5 sec with anti aliasing
So in milestone dev300m30 a severe performance decrease has happened.
@Armin, as no chart changes were integrated into that milestone, but CWS aw033
was, which changed a lot of basic things in the drawing engine, please have a
look! Thanks!
Comment 1 IngridvdM 2009-02-05 09:52:44 UTC
Created attachment 59943 [details]
example chart
Comment 2 Armin Le Grand 2009-02-05 12:28:01 UTC
AW: Accepting, but setting to 3.2 due to time constraints. Probably happening
since during the chart's geometry creation too much preparation for
visualisation may already be done (unnecessarily).
Comment 3 Armin Le Grand 2009-02-12 13:52:41 UTC
AW: Changed title
Comment 4 IngridvdM 2009-02-13 10:24:54 UTC
*** Issue 98205 has been marked as a duplicate of this issue. ***
Comment 5 stephan_schaefer 2009-02-16 14:51:30 UTC
CCed: ssa
Comment 6 Armin Le Grand 2009-05-14 10:29:38 UTC
AW: Discussed with IHA yestarday; she is not sure if she will get time to do
chart changes for using a MetaObject (one object, n transformations) to replace
e.g. 5000 chart points to one SdrObject, so i will have to remove this task and
put back.
Comment 7 IngridvdM 2009-05-18 17:22:32 UTC
@aw, there must have been a misunderstanding.
In case there is not enough time to implement the new feature of a
Meta-SdrObject (one object, n transformations) this should not hinder you at all
to analyze the reasons for this regression. The rendering was much faster in OOo
3.0 and there was no Meta-SdrObject. Furthermore that new feature will not help
e.g. for line charts where not so many sdr shapes are created but only a few
PolyLineShapes with bigger polygons. I'll attach an example with line charts.
Those line charts suffer from the same performance regression within rendering.
But they will not profit from the Meta-SdrObject feature.
Comment 8 IngridvdM 2009-05-18 17:27:48 UTC
Created attachment 62350 [details]
example with a big line chart
Comment 9 IngridvdM 2009-05-18 17:35:17 UTC
In the meanwhile I have identified two problems that have been a part of this
Issue 101925: A metafile replacement image was superfluously requested during
edit mode.
Issue 101928: Painting was actually performed twice instead of once.

When those two issues are fixed the rendering in the above example does need
This is faster than OOo 3.1 but still some factor 1,5 or so slower than OOo 3.0.

@aw, so I would like to ask you again to do a deeper performance analysis of the
rendering routines as those are you babys. Maybe there are some repeated
iterations or similar that can be saved. Thanks a lot in advance!
Comment 10 IngridvdM 2009-05-20 08:56:55 UTC
I think issue 97749 is the better issue to take for the meta-sdr-object feature
implementation instead.
Comment 11 Armin Le Grand 2009-07-23 13:32:43 UTC
AW: Need to wait for #i101491# (cws aw074) being integrated; before this (where
exactly such problems were already addressed) the results will not be good.
Removing from CWS aw075 again.
Comment 12 Armin Le Grand 2009-07-28 15:00:05 UTC
added comment
Comment 13 Armin Le Grand 2009-09-08 10:56:34 UTC
AW: Not sure what i can do for the 3.2 timeline (nearly closed), but taking
another look. Need to build sc, though, first...
Comment 14 Armin Le Grand 2009-09-08 12:56:09 UTC
AW: Made a direct comparison (side-by-side) of DEV300m29(a) (no primitives) and
m54(b). Rough measurements (counting).

Scrolling in activated mode: (a) 53s, (b) 10s. Much faster, visualisation much
better (a does simply show Harilines, that visualisation is wrong)

Scrolling deactivated mode: 3s both non-AAed, with AA (b) needs 4s

Activation AAed: 17S (a), 25s (b). Without AA, (b) activates in 14s.

Deactivation takes much longer in (a), full 4min 5s. In (b) we get 27s for AAed,
25 for non-AAed.

The initial statement, moving the legend in an activated chart, takes 20s in
(a), but only 11s in AAed (b) and only 8s in non-AAed (b).

Thus, all in all, we already got a good speedup, and remarkably low costs for AA
activation. Still keeping open, but moving to 3.3 (and removing from aw077).
Comment 15 Armin Le Grand 2010-06-08 10:23:53 UTC
AW: Adapted target
Comment 16 ooo 2011-03-14 15:39:25 UTC
setting fix priority for 3.4 to P4.
Comment 17 Armin Le Grand 2013-01-09 12:10:19 UTC
ALG: Checked the idea that it is slow because the polylines are that long; so that the OS will not draw fat lines with HW-Acceleration but fallback to SW-Renderer. Added temporarily a polygon splitter, but this is not the reason.
Comment 18 Marcus 2017-05-20 10:47:57 UTC
Reset assigne to the default "".