|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | Freeze Importing a Windows Word document containing .EMF or WMF | ||||||
|---|---|---|---|---|---|---|---|
| Product: | gsl | Reporter: | fulmine68 <ldegiorgi> | ||||
| Component: | code | Assignee: | AOO issues mailing list <issues> | ||||
| Status: | ACCEPTED --- | QA Contact: | |||||
| Severity: | Trivial | ||||||
| Priority: | P2 | CC: | issues | ||||
| Version: | OOo 2.0 | ||||||
| Target Milestone: | OOo 3.x | ||||||
| Hardware: | PC | ||||||
| OS: | All | ||||||
| Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
| Developer Difficulty: | --- | ||||||
| Attachments: |
|
||||||
|
Description
fulmine68
2005-11-19 10:01:16 UTC
Created attachment 31627 [details]
This tar.gz attachment contains the two test cases (.EMF and .WMF)
fulmine68 thanks for reporting and providing the bugdoc. indeed this looks like a freeze; my first guess after attaching the debugger was a deadlock but then continuing revealed that it loads but needs unacceptably long. Can you confirm that the document is loaded? I still consider this a serious (performance) bug. looks like z_inflate_flush () from libtl680li.so consumes most of the time. transferring to SJ and confirming. Thank you for your prompt reply. Today evening I'll try to open the documents and wait until (if) they are loaded. Stay tuned. Bye SJ->THB: This is double to one of your wmf clipping problems.
ntdll.dll!7c91b298()
msvcr71.dll!7c3416b3()
msvcr71.dll!7c3416db()
tl680mi.dll!basegfx::B2DPolyPolygon::count() + 0x9d9 C
tl680mi.dll!_gpc_polygon_clip() + 0x8b6 C
tl680mi.dll!PolyPolygon::ImplDoOperation() + 0x3d C++
tl680mi.dll!PolyPolygon::GetDifference() + 0x10 C++
> svt680mi.dll!WinMtfClipPath::ExcludeClipRect(const Rectangle & rRect={...})
Line 111 C++
svt680mi.dll!WinMtfOutput::ExcludeClipRect(const Rectangle & rRect={...})
Line 880 C++
svt680mi.dll!WMFReader::ReadRecordParams(unsigned short nFunction=1045)
Line 814 C++
svt680mi.dll!WMFReader::ReadWMF() Line 1071 C++
svt680mi.dll!ConvertWMFToGDIMetaFile(SvStream & rStreamWMF={...}, GDIMetaFile
& rGDIMetaFile={...}, unsigned char (void *, unsigned short)*
pCallback=0x01407750, void * pCallerData=0x00eee528) Line 86 + 0x74 C++
svt680mi.dll!GraphicFilter::ImportGraphic(Graphic & rGraphic={...}, const
String & rPath={...}, SvStream & rIStream={...}, unsigned short nFormat=0,
unsigned short * pDeterminedFormat=0x00000000, unsigned long nImportFlags=0)
Line 1572 + 0x1c C++
svt680mi.dll!GraphicFilter::FilterCallback(ConvertData * pData=0x00eee61c)
Line 2278 + 0x36 C++
svt680mi.dll!GraphicFilter::LinkStubFilterCallback(void * pThis=0x08b6e078,
void * pCaller=0x00eee61c) Line 2248 + 0xf C++
tl680mi.dll!Link::Call() + 0x11 C++
soffice.bin!0040549c()
soffice.bin!0040697b()
tl680mi.dll!Link::Call() + 0x11 C++
vcl680mi.dll!GraphicConverter::Import(SvStream & rIStm={...}, Graphic &
rGraphic={...}, unsigned long nFormat=11) Line 184 + 0xd C++
vcl680mi.dll!GfxLink::LoadNative(Graphic & rGraphic={...}) Line 307 + 0x1a C++
set target/component/subcomponent In OOo 2.3.1 on Linux the issue is still there. I have a document that took over 15 minutes to open, while Microsoft Office opens it immediately. Most of the time in OOo is spent in z_inflate_flush that is called from ConvertGDIMetaFileToWMF() from libtl680li.so Tested existing test case (Test_EMF_WMF.doc.tar.gz attached to the issue). Import takes over 1 minute CPU time. Lachin Urazov Feb 15-- It does seem to take excessive time - performance problem I ran the provided Test Case on A)1.7 Ghz P4 768 MB RAM Os: Win 2000 SP4 -- took 2:48 CPU time / 52 MB memory B)1.7 Ghz Centrino 512 MB RAM OS:Win XP SP3 -- took 2:18 CPU time / 66 MB memory whereas it takes !! 2 sec CPU time to open the same document using MS Word 2003 (19 MB memory) btw, using OOo_2.3.1_Win32Intel en-US build for both configurations. (refer to previous comment) @sj: Please take this one back, it's unlikely I'll find time for it... accepted |