Apache OpenOffice (AOO) Bugzilla – Issue 122923
Bad performance showing ODF with page size foreground pictures
Last modified: 2017-05-20 10:34:18 UTC
Steps how to reproduce with "AOO 4.0.0-Dev – German UI / German locale [AOO400m3(Build:9702) - Rev. 1503709 (2013-07-17) ]" on German German WIN7 Home Premium (64bit)", Common 4.0-dev User Profile: 1. Download sample document from <http://www.bielefeldundbuss.de/OOO_QA/sample20.odg> 2. Open Document from AOO Start Center > Document opens, shows first sheet 3. In Navigator pane click icon "Next page" Background text information appears immediately After 5 additional seconds page filling picture appears in it's final version. 4. Close document 10. Launch AOO 3.4.1 11. Redo Steps 2,3 Here the page filling picture appears within 1/2s or so Additional info: ---------------- a) This is a problem with a particular class of my documents with some common characteristics: - Imported from PDF - PDF has been created by an OCR SCAN b) not a general problem with imported PDF c) For me that makes AOO more or less unusable for editing these documents, but I doubt that many users are affected, so MINOR d) Regression because worked fine with 3.4.1 e) Already Reproducible with server installation of " AOO 4.0.0-Dev – English UI / German locale [AOO400m1(Build:9700) - Rev. 1457992 - Rev.1457606]" on German WIN7 Home Premium (64bit)", own separate user profile But here the effect is a little different, in step 2 a blurred view of the page filling picture appears immediately, the final version of the picture will appear after 5 seconds delay (PC working with maximum processor load) f) In original test in step 3 I sometimes also observe behavior due to "e"
The slow response is in step 2, compared with 2.4.3 instead 3.4.1. Rev. 1507307 Win 7
adjusting summary as it is about showing an ODF I can confirm this issue. Some further observations from my system. AOO 4.0.0 - memory footprint: - start and create new Draw document --> 35MB - loading the given document --> 134MB - closing the given document --> 90MB vs AOO 3.4.1 - memory footprint: - start and create new Draw document --> 37MB - loading the given document --> 67MB - closing the given document --> 46MB putting Armin as one of the experts on CC
I checked a similar ODF text document. Writer does not show the described defect. I checked a similar ODF text document containing graphics copied from Draw. Writer shows the described defect. I checked a similar ODF spreadsheet document. Calc shows the described defect. --> Looks like that Writer's own graphic implementation is not affected.
ALG: Checked and identified. The change compared to 3.4.1 is that the win-specific part uses GDI+ stuff for bitmap rendering now; so what happens is that Gdiplus::Bitmap instances get created for low-level painting based on the vcl Bitmap/BitmapEx classes. These instances are buffered, but thrown away after some seconds (currently after not being used for 60 seconds or - of course - when the Bitmap/BitmapEx it is based on is destroyed. This is needed for better and faster bitmap painting, fast zooming in/out with decent scaling quality, rotation, shear, etc. I checked the converters which create the Gdiplus::Bitmap instances on demand. These can be optimized for both cases (Bitmap and BitmapEx) by not using SetPixel but instead the Gdiplus::BitmapData approach (see docu on the web). Did that and the conversion gets much faster; for Bitmap I can even use memcpy (per scanline, GDI images may be bottom-up and have aligmnents); this makes these cases (big, non-24-bit images from scanners) much faster. For BitmapEx it also gets much faster with an inner loop, but memcpy is not possible due to the nature of BitmapEx having two sources of data: The Bitmap and the alpha channel which need to be mixed into a single Gdiplus::Bitmap in this conversion (who ever came up with this idea...?). This change leads to roughly the same speed as before, and I am using the debug version. Both work well and fast, should be possible to apply this to AOO401. Doing some more tests...
ALG: Checked with writer, and indeed it does not yet use the mechanism. Saved the 1st 8bit scan pic from the bugdoc, inserted in writer. This explains why zooming and scrolling in writer is slow in this configuration, much slower than in draw/impress/calc. This should either be used or will vanish when writer bitmap objects get changed to draw bitmap objects (the rotation issue...). Checked the code, it uses DrawGraphicWithPDFHandling from SwGrfNode which uses GraphicObject::DrawWithPDFHandling (in all cases except SVGs).
ALG: Experimented with BitmapBuffer, FncGetPixel, IMPL_CASE_GET_FORMAT and Scanline classes and created a converter which does convert more directly from BitmapBuffer from all formats (see defines in salbtype.hxx) and not internally convert to 24bit first, but this is even slightly slower than before, so I will not add that...
ALG: Done some more tests, looks good. Requesting 401 flag since this fix can be applied to 401 with low risk from my POV. Comitting changes...
"alg" committed SVN revision 1518160 into trunk: i122923 win only: improved bitmap handling for rendering
ALG: Setting as resolved, looking for the AOO401 flag.
"alg" committed SVN revision 1518176 into trunk: i122923 optimize place to add alpha to bitmaps which need rotation
approve showstopper request
ALG: Checked in AOO401 and comitted there
"alg" committed SVN revision 1518629 into branches/AOO401: i122923 optimize place to add alpha to bitmaps which need rotation
set target milestone
.
ALG: Corrected owner
ALG: OOps, somehow that version in AOO401 missed the changes in salbmp.cxx, need to add these...
ALG: Added missing stuff
"alg" committed SVN revision 1520504 into branches/AOO401: i122923 Added missing stuff from that task
Verified on AOO401m4(Build:9713) - Rev. 1521921 on Win7,Pass