Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Performance: metafile creation is requested superfluously during inplace editing | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | General | Reporter: | IngridvdM | ||||||||
Component: | chart | Assignee: | joerg.skottke | ||||||||
Status: | CLOSED FIXED | QA Contact: | issues@graphics <issues> | ||||||||
Severity: | Trivial | ||||||||||
Priority: | P3 | CC: | Armin.Le.Grand, IngridvdM, issues, kyoshida | ||||||||
Version: | 3.3.0 or older (OOo) | Keywords: | performance, regression | ||||||||
Target Milestone: | --- | ||||||||||
Hardware: | All | ||||||||||
OS: | All | ||||||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||||||
Developer Difficulty: | --- | ||||||||||
Attachments: |
|
Description
IngridvdM
2009-05-14 15:59:45 UTC
I identified the superfluous call coming from ViewObjectContactOfSdrOle2Obj::createPrimitive2DSequence, currently working on a solution and testing. The current fix breaks pdf export. Have to debug further. Target changed to a better one (2.3 is gone since quite some time ;-)) This was of course only transposed digits. It should have been 3.2. I correct the target again. @aw, the pdf export is broken because ChartPrimitive2D::getB2DRange() does return an empty range as no concrete primitive is available at that moment. ChartPrimitive2D::getB2DRange() so far was simply the base class implementation. I have overloaded that method and implemented it thus now the size is retrieved directly from the chart model and not from the primitive sequences anymore. The new solution works fine so far. Please have a look at the attached patch as this is your code area. Thanks in advance! Created attachment 62541 [details]
patch to fix sub-problem with pdf export
@aw, thanks for the off-line review! I have tested the discussed changes and they work fine. The pure transformation is sufficient for the calculation of the range. Fixed in CWS dr70. Created attachment 62801 [details]
example for testing
->jsk, please verify in CWS dr70. For testing load the attached document BigLineChart.ods, switch off the tip help to avoid arbitrary repaints, double click the chart, double click the y-axis and set the scale maximum to 95. Click ok and move the mouse left and right to see when the chart is ready for new user actions (pointer changes dependent on where you are). Observe how long the time is from clicking ok until the chart is repainted with the new maximum and is ready for further user actions again. On my computer it takes: dev300m49: ~1 minute and 13 seconds CWS dr70: ~12 seconds The changed code is a quite central place that potentially affects the painting of all OLE objects. So please ensure that other OLE objects and the chart are still painted correctly on screen, pdf export and printing. I'll attach a small example with some different OLE objects. Created attachment 62802 [details]
example with some different OLE objects
@jsk, please also ensure that OLE objects are still painted correctly on screen while in edit mode and not in edit mode. Thanks! My mesurements show even better performance gain - 1:34 / 0:11. Tested OLE objects (Add new, editing, add more, edit more, switch between objects, move, resize) and calc related OLE object autotests succeeded. Verified. Close |