Apache OpenOffice (AOO) Bugzilla – Issue 98402
PDF Export: Dramatic Performance Regression
Last modified: 2013-08-07 14:43:11 UTC
When exporting documents containing JPEG files to PDF, in DEV300 (checked m39) performance decreased dramatically, compared to OOO300. OOO300 m15 : Lossless JPEG Compression : 3 secs OOO300 m15 : 90% quality JPEG compression : 10 secs DEV300 m39 : Lossless JPEG Compression : 2 minutes DEV300 m39 : 90% quality JPEG compression : 6 minutes
Created attachment 59626 [details] bugdoc, 49 pages, 100 jpeg pictures
As discussed with sj reassigned
sj->od: If exporting the test document to pdf the jpeg import is called ~5000 times about 100 should be sufficient. It seams that for each page the whole bunch of graphics are imported once. swmi.dll!SwGrfNode::ImportGraphic(SvStream & rStrm={...}) Line 408 C++ swmi.dll!SwGrfNode::SwapIn(unsigned char bWaitForData='') Line 481 + 0xf bytes C++ swmi.dll!SwNoTxtFrm::PaintPicture() + 0xdb bytes C++ swmi.dll!SwNoTxtFrm::Paint() + 0x2b7 bytes C++ swmi.dll!SwLayoutFrm::Paint(const SwRect & rRect={...}) Line 3278 C++ swmi.dll!SwFlyFrm::Paint(const SwRect & rRect={...}) Line 3697 C++ swmi.dll!SwVirtFlyDrawObj::wrap_DoPaintObject() + 0x5f bytes C++ swmi.dll!drawinglayer::primitive2d::SwVirtFlyDrawObjPrimitive::get2DDecomposition() + 0xe bytes C++ drawinglayermi.dll!drawinglayer::processor2d::VclMetafileProcessor2D::processBasePrimitive2D(const drawinglayer::primitive2d::BasePrimitive2D & rCandidate={...}) Line 1658 + 0x1e bytes C++ drawinglayermi.dll!drawinglayer::processor2d::BaseProcessor2D::process(const com::sun::star::uno::Sequence<com::sun::star::uno::Reference<com::sun::star::graphic::XPrimitive2D> > & rSource=[100]({0x0e8f9958},{0x0f040eb0},{0x0e8f9918},{0x0f040c70},{0x0e8f9cd8},{0x0f040cf0},{0x0fa95334},{0x0f040430},{0x0b02bccc},{0x0b02bd0c},{0x0f040870},{0x0f0408b0},{0x0f0408f0},{0x0b02bf0c},{0x0f0409b0},{0x0e8f9458},{0x0e8f9498},{0x0fa95034},{0x0b02becc},{0x0f040d70},{0x0b02be8c},{0x0dbb3a14},{0x0db94790},{0x0db94690},{0x0db94610},{0x0db94510},{0x0db94210},{0x0db94450},{0x0db94390},{0x0db94250},...,...)) Line 85 C++ svxmi.dll!sdr::contact::ObjectContactOfPageView::DoProcessDisplay(sdr::contact::DisplayInfo & rDisplayInfo={...}) Line 259 C++ svxmi.dll!sdr::contact::ObjectContactOfPageView::ProcessDisplay(sdr::contact::DisplayInfo & rDisplayInfo={...}) Line 143 C++ svxmi.dll!SdrPageWindow::RedrawLayer(const unsigned char * pId=0x0162cc30, sdr::contact::ViewObjectContactRedirector * pRedirector=0x00000000) Line 398 C++ svxmi.dll!SdrPageView::DrawLayer(unsigned char nID='', OutputDevice * pGivenTarget=0x0e5ff4a8, sdr::contact::ViewObjectContactRedirector * pRedirector=0x00000000) Line 413 C++ swmi.dll!SwViewImp::PaintLayer() + 0x142 bytes C++ swmi.dll!SwRootFrm::Paint(const SwRect & rRect={...}) Line 2977 C++ swmi.dll!ViewShell::Prt() + 0xa4e bytes C++ swmi.dll!SwXTextDocument::render() + 0x461 bytes C++
defect cause found together with AW: During PDF export the check which object have to painted for a certain view range does not work as expected. The view range is not set to the area, which is painted. defect cause has been introduced in DEV300m30.
OD->AW: As figured out together, in method ObjectContactOfPageView::DoProcessDisplay(..) the clip region needs to be used as the view range, when exporting to PDF. Please take over - Thx.
AW: Checking. Adding needed code to ObjectContactOfPageView::DoProcessDisplay. Need to test with the other PDF exports, of course. Experimenting...
AW: Needed to add partial changes from #i97982# from aw062 to get the isOutputToPDFFile() function at OCs. Implemented and rebuilt SVX and applications incompatible. Works as expected, checked with SC and SD, too. Checking in.
AW: Checked in, marked aw063 incompatible from svx, done.
AW->WG: Please verify. This is a SW task, evtl. also forward to SW testing.
Reassigned. Please verify in aw063. Thanks!
Reassigned. Please verify.
SBA->HI: As discussed, please proceed, thx.
Verified with cws aw063 = ok
Verified in DEV310m7 on WinXP and Fedora. Export to pdf file normally. Closing Li Meiying