Issue 102063 - performance: Metafile replacement images are requested for charts even if they are not visible
Summary: performance: Metafile replacement images are requested for charts even if the...
Status: CLOSED FIXED
Alias: None
Product: Draw
Classification: Application
Component: viewing (show other issues)
Version: DEV300m47
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: wolframgarten
QA Contact: issues@graphics
URL:
Keywords: performance, regression
Depends on:
Blocks:
 
Reported: 2009-05-19 14:59 UTC by IngridvdM
Modified: 2017-05-20 10:29 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
loading the example shows the superfluous call (14.00 KB, application/vnd.ms-excel)
2009-05-19 15:04 UTC, IngridvdM
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description IngridvdM 2009-05-19 14:59:23 UTC
Load the attached xls document. There is a chart on the second sheet that is not
visible when the document is loaded. Nevertheless the drawinglayer requests a
metafile replacement image from the chart. This can be extreme expensive when
the chart is bigger.
This superfluous expensive call must be avoided. It is a regression as the
metafile was not requested within OOo 3.0.
Comment 1 IngridvdM 2009-05-19 15:04:55 UTC
Created attachment 62372 [details]
loading the example shows the superfluous call
Comment 2 IngridvdM 2009-05-19 15:09:04 UTC
Here is the call stack that leads to the superfluous potentially very expensive
metafile creation:
chartviewmi.dll!chart::ChartView::getMetaFile() 
chartviewmi.dll!chart::ChartView::getTransferData() 
chartmodelmi.dll!chart::ChartModel::getPreferredVisualRepresentation() 
embobj.dll!644e5c0d() 	
[Frames below may be incorrect and/or missing, no symbols loaded for embobj.dll]	
utlmi.dll!5c171e07() 	
comphelp4MSC.dll!6598735f() 	
comphelp4MSC.dll!659e1838() 	
svtmi.dll!57d8667f() 	
svtmi.dll!57d870fa() 	
svtmi.dll!57d8775d() 	
svtmi.dll!57d877d5() 	
svxmi.dll!SdrOle2Obj::GetGraphic() 
svxmi.dll!sdr::contact::ViewContactOfSdrOle2Obj::createViewIndependentPrimitive2DSequence()

svxmi.dll!sdr::contact::ViewContact::getViewIndependentPrimitive2DSequence() 
svxmi.dll!SdrObject::RecalcBoundRect() 
svxmi.dll!SdrObject::GetCurrentBoundRect() 
svxmi.dll!SdrObjList::NbcInsertObject() 

Comment 3 IngridvdM 2009-05-19 15:21:24 UTC
For a real life example see issue 101491 which points to the attachment at issue
101434.
Comment 4 Armin Le Grand 2009-07-23 16:36:43 UTC
AW: Added to CWS aw075, taking a look. Problem is probably that someone wants
the object's BoundRect, even when not visualized
Comment 5 Armin Le Grand 2009-07-23 16:48:40 UTC
AW: As i thoght. When the object (the OLE) is inserted into the PageList, the
list tries to keep up-to-date it's buffered BoundRect and gets it from the
object. This uses the prmitives who's decomposition has to get the graphic as
content. In principle, it is already wrong that the Page's ObjectList asks for a
BoundRect; BoundRects only make sense with a view (not at the pure model). This
is old stuff and too dangerous to touch currently, it's a candidate for the
model rework.
There is another possibility with primitives; implement an in-between primitive
which implements a getB2DRange() method and thus will not need to decompose
itself. This is handy anyways and will allow encapsulating HighContrast, scaled
(EmptyPresObj) visualisation and other special stuff. Since the SDrObject allows
a WeakReference nowadays, it is also safely implementable (primitive lifetime).
Trying...
Comment 6 Armin Le Grand 2009-07-23 16:53:19 UTC
AW: Works very well. Checked for outplace editing visualisations, empty PresObjs
and (of course) with loading the bugdoc. The graphic is no longer needed.
Checking in. Also cleaned up executeOldDoPaintPreparations which is no longer
needed (there is NO excuse with CWSes to not remove stuff immediately nowadays...).
Done.
Comment 7 Armin Le Grand 2009-08-04 16:38:29 UTC
AW: Checked in test build, okay. Best check is that reload is much faster now;
the work (chart creation) is done by changing to 2nd sheet
Comment 8 Armin Le Grand 2009-08-06 13:44:19 UTC
AW->WG: Please review. IHA may help. but difference is that reload is much
faster since the chart on 2nd sheet is not created. Can be seen even better when
changing the chart to 3D (takes longer)
Comment 9 wolframgarten 2009-08-10 10:19:13 UTC
Verified in CWS.