Apache OpenOffice (AOO) Bugzilla – Issue 58151
Freeze Importing a Windows Word document containing .EMF or WMF
Last modified: 2013-02-07 21:50:27 UTC
I work in an Microsoft Office 2003 environment. So I exchange a lot of documents with them. Each of these docs contains a mixture of text and graphics, mainly in EMF (Enhanced Meta File) or WMF (Windows Enhanced Metafile). When I try to import those documents OO Writer ehaves in the following ways: EMF: the doc imports fine. OO Writer freezes when I zoom in or zoom out WMF: OO Writer freezes on import All is fine when importing a doc with .PNG or .JPG images I have documents to test this behaviour
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