Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||performance: rendering charts takes much longer than before|
|Component:||ui||Assignee:||AOO issues mailing list <issues>|
|Status:||ACCEPTED ---||QA Contact:|
|Priority:||P4||CC:||ahz001, issues, ooo, stephan_schaefer|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
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 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
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 regression: 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 ~2-3sec. 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
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.