Issue 122923 - Bad performance showing ODF with page size foreground pictures
Summary: Bad performance showing ODF with page size foreground pictures
Alias: None
Product: Draw
Classification: Application
Component: viewing (show other issues)
Version: 4.0.0
Hardware: PC Windows 7
: P3 Minor (vote)
Target Milestone: 4.0.1
Assignee: Armin Le Grand
QA Contact: Edwin Sharp
Keywords: regression
Depends on:
Reported: 2013-08-01 04:59 UTC by Rainer Bielefeld
Modified: 2017-05-20 10:34 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---
jsc: 4.0.1_release_blocker+


Note You need to log in before you can comment on or make changes to this issue.
Description Rainer Bielefeld 2013-08-01 04:59:36 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 
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
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"
Comment 1 Edwin Sharp 2013-08-06 07:30:27 UTC
The slow response is in step 2, compared with 2.4.3 instead 3.4.1.

Rev. 1507307 Win 7
Comment 2 Oliver-Rainer Wittmann 2013-08-26 09:32:17 UTC
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
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
Comment 3 Oliver-Rainer Wittmann 2013-08-26 09:58:02 UTC
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.
Comment 4 Armin Le Grand 2013-08-27 16:02:00 UTC
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...
Comment 5 Armin Le Grand 2013-08-27 16:44:04 UTC
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).
Comment 6 Armin Le Grand 2013-08-28 10:42:47 UTC
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...
Comment 7 Armin Le Grand 2013-08-28 11:13:37 UTC
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...
Comment 8 SVN Robot 2013-08-28 11:15:42 UTC
"alg" committed SVN revision 1518160 into trunk:
i122923 win only: improved bitmap handling for rendering
Comment 9 Armin Le Grand 2013-08-28 11:26:20 UTC
ALG: Setting as resolved, looking for the AOO401 flag.
Comment 10 SVN Robot 2013-08-28 12:26:33 UTC
"alg" committed SVN revision 1518176 into trunk:
i122923 optimize place to add alpha to bitmaps which need rotation
Comment 11 jsc 2013-08-29 11:33:19 UTC
approve showstopper request
Comment 12 Armin Le Grand 2013-08-29 13:05:49 UTC
ALG: Checked in AOO401 and comitted there
Comment 13 SVN Robot 2013-08-29 13:06:56 UTC
"alg" committed SVN revision 1518629 into branches/AOO401:
i122923 optimize place to add alpha to bitmaps which need rotation
Comment 14 jsc 2013-08-30 09:12:44 UTC
set target milestone
Comment 15 jsc 2013-08-30 09:13:08 UTC
Comment 16 Armin Le Grand 2013-09-03 10:35:51 UTC
ALG: Corrected owner
Comment 17 Armin Le Grand 2013-09-05 17:24:44 UTC
ALG: OOps, somehow that version in AOO401 missed the changes in salbmp.cxx, need to add these...
Comment 18 Armin Le Grand 2013-09-06 08:01:27 UTC
ALG: Added missing stuff
Comment 19 SVN Robot 2013-09-06 08:32:48 UTC
"alg" committed SVN revision 1520504 into branches/AOO401:
i122923 Added missing stuff from that task
Comment 20 liuping 2013-09-13 06:24:52 UTC
Verified on AOO401m4(Build:9713)  -  Rev. 1521921 on Win7,Pass