|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | performance: rendering charts takes much longer than before | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Draw | Reporter: | IngridvdM | ||||||
| Component: | ui | Assignee: | AOO issues mailing list <issues> | ||||||
| Status: | ACCEPTED --- | QA Contact: | |||||||
| Severity: | Trivial | ||||||||
| Priority: | P4 | CC: | ahz001, issues, ooo, stephan_schaefer | ||||||
| Version: | DEV300m30 | Keywords: | performance, regression | ||||||
| Target Milestone: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||||
| Developer Difficulty: | --- | ||||||||
| Attachments: |
|
||||||||
|
Description
IngridvdM
2009-02-05 09:51:19 UTC
Created attachment 59943 [details]
example chart
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). AW: Changed title *** Issue 98205 has been marked as a duplicate of this issue. *** CCed: ssa 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. @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. Created attachment 62350 [details]
example with a big line chart
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! I think issue 97749 is the better issue to take for the meta-sdr-object feature implementation instead. 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. added comment AW: Not sure what i can do for the 3.2 timeline (nearly closed), but taking another look. Need to build sc, though, first... 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). AW: Adapted target setting fix priority for 3.4 to P4. 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. Reset assigne to the default "issues@openoffice.apache.org". |