Slow, very slow work with bigger size of picture inside Draw. Impossible for easy work.
AOO400m3(Build:9702)  -  Rev. 1503704
2013-07-16 14:54:56 (Di, 16 Jul 2013)

Link for Draw document:
https://docs.google.com/uc?export=download&id=0B_xv-Bc9VISwb0hPSFk1Y0lpQXM

I can confirm the bad performance. Take a common photo from a digital camera. I have used a 2,7MB JPEG-photo. A 90° rotation needs 2 seconds, a move 3 seconds, loading 7 seconds. AOO3.4.1 makes 90° rotation in 1 second, a move immediately and loading in 3 seconds.

Especially the delay in moving makes working with photos virtually impossible.

put Armin on CC as he is one of the experts here

Wittmann, how to do that? I am new here.. :)

(In reply to sevalav from comment #5)
> Wittmann, how to do that? I am new here.. :)

Oh sorry...
I meant to say that "I have put Armin on CC as ...."


But nevertheless, in order to put somebody on CC of an issue you have to found the CC List field in the upper right corner. There is a link the start the edit mode. In the edit mode you can add the corresponding person.
I am not sure, if a certain access right is needed to edit the CC List field.

In AOO 3.4.1 there is not present this problem.

adjusting Issue Type as this is a defect.

ALG: Already speeded up stuff for rendering and conversion to Gdiplus::Bitmap in task #122923#, this should bring it back to comparable speeds as before.

Still I took a look at JPEGReader::Read. To mention before: Nothing was changed there, but it uses ca. 17% of it's time to read the jpeg and the *rest* to get it to a Bitmap as content. This is because SetPixel() calls are used and jpeg's imported format is RGB while the 24bit bitmap uses GBR internally. There is no GBR import format available from the jpeg importer unfortunately.
Tried to use CopyScanline at BitmapWriteAccess using BMP_FORMAT_24BIT_TC_RGB. This works but is not much faster as SetPixel() since the internal format conversion is not very fast.
But using BMP_FORMAT_24BIT_TC_BGR and first 'switching' all 1st and 3rd bytes in a loop makes it much faster. With this additional speedup for jpeg we sould be better than before. Preparing checking this in.

Also took a look at the swap stuff in current GraphicObjects; these all get swapped out after 5000ms (5 seconds), independent of the time set in tools/options/memory/Remove_from_memory_after setting. This seems wrong and makes switching pages very slow since loading has to reoccur often. Taking a look...

AG: Checked what happens when not setting a swap time at all; idea was that the GraphicManager (which at least reads the timeout from the settings in GraphicObject::ImplSetGraphicManager and sets it at the global GraphicCache) would then swap out all GraphicObjects after the given time, but this does not work. Reading the setting itself and set it instead of the 5000ms works well; still has its weaknesses since it *tests* for swap out every e.g. 10 minutes (if set so), also no 'touch' when the graphic is used to reset the timer is there (what would be normal for a cache). What to do...?

ALG: Checked svtools jpeg load changes on linux to be on the safe side, all works well and is faster, too.

ALG: Did the same I dod for jpeg (see comment 9) for png, got improvements from 10s load time to 2s. Only done for 24/32bit and not preview-loading to minimize risk, checked with a PNG test suite all optimized cases. Need to check this one on linux, too.
Also experimenting with the time settings to flush graphics; when using the default from the tools/options of 10 minutes (instead of the hard-coded 5 seconds) exactly that happens; there is no mechanism to make the GraphicManager to take the used memory or number of cached GraphicObjects lead to flushing graphics (this needs rework). When I would set that time correct, this may lead to memory problems in other cases. Maybe the speedups should be all for now, to be on the safe side...

ALG: Looking for a good compromize with the swap-out time: The default is 10 minutes. The minimum is one minute, thus 60 seconds. When the minimum should match to the former hard-coded 5 seconds, we have a divisor of 12 to use. For the default of 10 minutes this would mean 50 seconds. Compared to before this is ten times more (would allow better navigation by switching through pages) and is controllable by the user by setting the tools/options/memory/Remove_from_memory_after setting. Seems to be a good compromize to me. Checked in a living office, feels good.

ALG: Checking all changes on Linux...

ALG: Linux check led to slight adaptions in png importer, works well, adapting to win version. Adding comments and preparing commit...

ALG: Also saw that deleting graphic objects does not flush the graphic content since these objects go to the undo stack. Added code to do this when objects get deleted and move to the undo stack. This will help when adding/removing a lot of pictures (e.g. D&D copy/paste from explorer or similar). Checking...

ALG: Works like a charm, adding this. GraphicObjects get flushed when deleted or redoing a delete. Preparing commit, setting AOO401 flag, too.

"alg" committed SVN revision 1520296 into trunk:
i122985 Various speedups for graphic object swapping to enhance user experience

ALG: Testing final version on Linux and AOO401...

approve showstopper request

ALG: Looks good, found a missing part of #122923# which was needed, added. Preparing commit for AOO401...

"alg" committed SVN revision 1520507 into branches/AOO401:
i122985 Various speedups for graphic object swapping to enhance user experience

"hdu" committed SVN revision 1521489 into branches/AOO401:
#i122985# fix compile error in pngreader.cxx for product build with debug ena...

"hdu" committed SVN revision 1521488 into trunk:
#i122985# fix compile error in pngreader.cxx for product build with debug ena...

Verified on AOO401m4(Build:9713)  -  Rev. 1521921 on Win7,Pass

Verified on AOO401m4(Build:9713)  -  Rev. 1521921 on Linux,Pass